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Dear Sir: 

Applicant (Appellant) hereby submits this Reply Brief pursuant to 37 C.F.R. § 41 .41 in 
connection with the above-referenced application and respectfully requests consideration by 
the Board of Patent Appeals and Interferences for allowance from a fourth and/or fifth 
rejection decision by the Examiner. The confusion as to a fourth or fifth rejection is based 
as discussed below on the Examiner failing to comply with Examiner Answer requirements 
as noted in the MPEP, for which Appellant asks the Board to reject in whole the Examiner's 
Answer. The Examiner's fourth rejection decision ("Office Action" or "Office") was mailed on 
March 23, 2006 and rejected all claims (1-27). The Examiner's fifth rejection decision is 
presumably somewhere within the Examiner's Answer. Applicant submitted a Notice of 
Appeal that was received on September 29, 2006. 
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Because of the Examiner failing to comply with the mandatory requirements as listed 
under MPEP 1207(A) and the uncertainty of what the new grounds of rejection are or which 
claims are encompassed therein, the Applicant is caught in a Catch-22 and thus is 
incorporating by reference in its entirety the original Appeal Brief as it is applicable to those 
claims which are not under new grounds of rejection or addressed directly herein. For 
completeness and to make sure that claims are not dismissed by a non-response. Applicant 
is being forced to assume all claims are under new grounds of rejection and thus arguments 
which may or may not be applicable are included. Applicant requests the Board's patience. 

Applicant respectfully requests that because the Examiner did not comply with 
1207(A)(6)(d) that the Board reject in entirety the Examiner's Answer. 

Applicant also notes for the Board that the Examiner has failed to include rebuttal 
arguments to the Appeal Brief for claims 11-18 and 20-27. As noted in MPEP 1 207.02 
"...any rejection not repeated and discussed in the answer may be taken by the Board as 
having been withdrawn. Ex parte Emm, 118 USPQ 180 (Bd. App. 1957). Applicant 
respectfully submits that claims 11-18 and 20-27 have been withdrawn from rejection by the 
Examiner and thus are allowable and requests such allowance. 
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I. REAL PARTY IN INTEREST 

The real party in interest of Appellant is Digi International, Incorporated. 

II. RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of any related appeals or interferences. 

1 ) There are no prior or pending interferences. 

2) There are no pending appeals before the USPTO. 

3) There is no judicial proceeding related to Appellant's instant application or related 
applications. 

III. STATUS OF THE CLAIMS 

Claims 1-27 are pending in the application. The status of the claims is unclear 
because as noted above the Examiner has implicitly withdrawn rejections by not providing a 
rebuttal in the Answer. 

All suitable claims are on appeal as explained above in the Catch-22 discussion. 
Applicant submits that claims 11-18 and 20-27 have been made allowable by the Examiner. 

Various claims have been rejected by the Examiner. 

In the fourth Office Action ("Fourth Office"), Claims 1-27 were rejected under 35 
U.S.C. § 101 as being directed to non-statutory subject matter. Claims 1-27 were rejected 
under 35 U.S.C. § 102(e) as being anticipated by Bavadekar (U.S. Patent Application No. 
2003/0009571 A1). 
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In the fifth Office Action under the new grounds of rejection somewhere in the 
Examiner's Answer ("Fifth Answer"), Applicant is not certain which claims are newly rejected. 
As such Applicant will be assuming arguendo all claims are newly rejected. 



IV. STATUS OF AMENDMENTS 

No amendments have been filed after receipt of the fourth or fifth rejection. 

// 
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V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

Appellant has indicated below representative Figures/Specifications - not all are 
included so as to keep the claims brief. Appellant has indicated in larger font the three 
independent claims (1, 10, and 19). 

1. A computer network architecture (Figure 2 Specification: page 8, lines 17- 
18; page 30, line 1.) comprising: 

a first layer including a transmission control protocol connection; 

(Figure 2 at 222 (Transport Layer). Specification: page 8, line 22; page 30, line 2.) 

a second layer including a hypertext transfer protocol connection 
(Figure 2 at 232 (HTTP). Specification: page 9, lines 3-5; page 30, line 3.) built upon the 
first layer; 

a first tunneling layer including a first tunneling protocol built upon 
the second layer to tunnel a message through the hypertext transfer 
protocol connection; (Figure 2 at 240 (MDH). Specification: page 9, lines 3-5.) and 

a multiplexing layer to multiplex a plurality of messages for 
transmission through the first tunneling layer. (Figure 2 at 270 (Multiplexing 
Layer). Specification: page 9, lines 12-14.) 
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2. The computer network architecture of claim 1, wherein the first tunneling 
protocol opens the hyper text transfer protocol connection between a server and a 
client. (Figure 4, at 410, 420. Specification: page 10, lines 16-21.) 

3. The computer network architecture of claim 1, further comprising: 

a second tunneling layer including a second tunneling protocol (Figure 2 at 226. 
Specification: page 9, lines 6-7.) built upon the first layer to tunnel a message through 
the transmission control protocol connection. (Figure 2 at 222. Specification: page 8, 
line 22.) 

4. The computer network architecture of claim 3, wherein the second tunneling 
protocol (Figure 2 at 226. Specification: page 9, lines 6-7) is used to open the 
transmission control protocol connection between the server and the client. (Figure 4 
at 422. Specification: page 10, lines 7-15.) 

5. The computer network architecture of claim 4, wherein the first tunneling 
protocol (Figure 11 at 1 140 (MDH protocol).) opens the hyper text transfer protocol 
connection if the second tunneling protocol (Figure 11 at 1 1 1 0 (MI protocol).) is not 
successful in opening the transmission control protocol connection (Figure 1 1 at 
1120.). (Figurell. Specification: page 22, line 19 to page 23, line 8.) 

6. The computer network of claim 1, wherein the messages include binary format 
messages. (Specification: page 7, line 18.) 
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7. The computer network architecture of claim 1, wherein the plurality of 
messages includes a plurality of operational messages (Specification: page 17, line 1 1 .) 
and a plurality of administrative messages. (Specification: page 18, lines 2, 10-1 1 .) 

8. The computer network architecture of claim 7, wherein the operational 
messages include operational data. (Specification: page 18, line 16.) 

9. The computer network architecture of claim 7, wherein the administrative 
messages can be selected from the group consisting of debug messages, firmware 
update messages and parameter configuration messages. (Specification: page 26, 
lines 1-3.) 

10. A method for a computer network architecture comprising: 

building a hyper text transfer protocol connection upon (Figure 2 at 
232 (HTTP). Specification: page 9, lines 3-5; page 30, line 3.) a transmission control 
protocol connection; (Figure 2 at 222 (Transport Layer). Specification: page 8, line 
22; page 30, line 2.) 

tunneling a message through the hypertext transfer protocol 
connection by using a first tunneling protocol layer including a first 
tunneling protocol; (Figure 2 at 240 (MDH). Specification: page 9, lines 3-5.) and 
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multiplexing a plurality of messages for transmission through the 
hyper text transfer protocol connection by using a multiplexing layer. 

(Figure 2 at 270 (Multiplexing Layer). Specification: page 9, lines 12-14.) 

1 1 . The method of claim 1 0, wherein opening the hyper text transfer protocol 
connection between a server and a client by using the first tunneling layer. (Figure 5 
at 502 (MDH Connection Request). Specification: page 11, lines 2-3.) 

12. The method of claim 10, further comprising: 

tunneling a message through the transmission control protocol connection 

(Figure 2 at 222. Specification: page 8, line 22.) by using a second tunneling protocol 
layer including a second tunneling protocol built upon (Figure 2 at 226 (MI). 
Specification: page 9, lines 6-7.) the transmission control protocol connection. (Figure 
2 at 222. Specification: page 8, line 22.) 

13. The method of claim 12, wherein opening the transmission control protocol 
connection between a server and a client by using the second tunneling protocol. 

(Figure 11 at 1 1 1 0. Specification: page 22, lines 20-21 .) 

14. The method of claim 13, wherein opening the hyper text transfer protocol 
connection by using the first tunneling protocol if the transmission control protocol 
connection is not successfully opened by using the second tunneling protocol. 

(Figure 11 at 1 120, 1 140. Specification: page 23, lines 2-4.) 
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15. The method of claim 10, wherein the messages include binary format 
messages. (Specification: page 7, line 18.) 

16. The method of claim 10, wherein the plurality of messages include a plurality of 
operational messages (Specification: page 17, line 11.) and a plurality of administrative 
messages. (Specification: page 18, lines 2, 10-11.) 

17. The method of claim 16, wherein the operational messages include operational 
data. (Specification: page 18, line 16.) 

18. The method of claim 16, wherein the administrative messages can be selected 
from the group consisting of debug messages, firmware update messages and 
parameter configuration messages. (Specification: page 27, lines 19-21.) 

19. A computer readable medium (Figure 10 at 1006, 1008, lOIO. Specification: 
page 23, lines 15-16 ) having instructions which, when executed by a 
processing system (Figure 10 ) , cause the system to perform a method 
comprising: 

building a hyper text transfer protocol connection upon (Figure 2 at 
232 (HTTP). Specification: page 9, lines 3-5; page 30, line 3.) a transmission control 
protocol connection; (Figure 2 at 222 (Transport Layer). Specification: page 8, line 
22; page 30, line 2.) 
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tunneling a message through the Hyper Text Transfer Protocol 
connection by using a first tunneling protocol layer including a first 
tunneling protocol; (Figure 2 at 240 (MDH). Specification: page 9, lines 3-5.) and 

multiplexing a plurality of messages for transmission through the 
Hyper Text Transfer Protocol connection by using a multiplexing layer. 
(Figure 2 at 270 (Multiplexing Layer). Specification: page 9, lines 12-14.) 

20. The medium of claim 19, wherein opening the Hyper Text Transfer Protocol 
connection between a server and a client by using the first tunneling layer. (Figure 5 
at 502 (MDH Connection Request). Specification: page 11, lines 2-3.) 

21. The medium of claim 19, further comprising: 

tunneling a message through the transmission control protocol connection 

(Figure 2 at 222. Specification: page 8, line 22.) by using a second tunneling protocol 
layer including a second tunneling protocol built upon (Figure 2 at 226 (MI). 
Specification: page 9, lines 6-7.) the Transmission Control Protocol Connection. (Figure 
2 at 222. Specification: page 8, line 22.) 

22. The medium of claim 21, wherein opening the Transmission Control Protocol 
connection between a server and a client by using the second tunneling protocol. 

(Figure 11 at 1 1 1 0. Specification: page 22, lines 20-21 .) 
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23. The medium of claim 22, wherein opening the Hyper Text Transfer Protocol 
connection by using the first tunneling protocol (Figure 11 at 1120 (NO), 1140.) if the 
Transmission Control Protocol connection is not successfully opened by using the 
second tunneling protocol. (Figure 11 at 1 120 (NO), 1 140. Specification: page 23, lines 
2-4.) 

24. The medium of claim 19, wherein the messages include binary format 
messages. (Specification: page 7, line 18.) 

25. The medium of claim 19, wherein the plurality of messages include a plurality 
of operational messages (Specification: page 17, line 1 1 .) and a plurality of 
administrative messages. (Specification: page 18, lines 2, 10-11.) 

26. The medium of claim 25, wherein the operational messages include operational 
data. (Specification: page 18, line 16.) 

27. The medium of claim 25, wherein the administrative messages can be selected 
from the group consisting of debug messages, firmware update messages and 
parameter configuration messages. (Specification: page 29, lines 15-17.) 

// 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The issues presented on appeal are whether Applicant's claims 1-27 as may be 
applicable in view of the discussion above for the reasons stated in the Status of the Claims 
are unpatentable. 

First 

Some of Claims 1-27 stand rejected under 35 U.S.C. § 101 as being directed to non- 
statutory subject matter. 

Second 

Some of Claims 1-27 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
Bavadekar(U.S. Patent Application No. 2003/0009571 A1. 

// 
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VII. ARGUMENT 

PREFACE 

Board of Appeals, 

It is this type of examination on the instant application that is driving us conscientious patent 
attorneys up the wall. 

Before the Appeal we have had 3 prior office actions where the Applicant successfully 
overcame the Examiner's arguments without amending any claims only to be met with a 
new rejection based on "applicant's arguments moot in light of new art." 

Then on the 4"^ rejection, the Examiner raised for the first time a 101 rejection. What kind of 
examination is being done by this Examiner? A 101 should have been raised previously. A 
response by the examiner of "only now do I understand what applicant is trying to claim" is a 
lame excuse as Applicant has not amended anything! 

Now in response to our Appeal the Examiner in his Answer is raising "new grounds of 
rejections". I wonder if there is any finality or if the Examiner will next yank the application 
back into prosecution so as to avoid the Board seeing this appeal? 

Applicant suspects that the Examiner is not happy that the techniques disclosed and 
claimed for in the patent application, while new, non-obvious, and novel at the time of the 
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invention, may now be known and the Examiner is suffering a case of Monday morning 
quarterbacking. 

Applicant respectfully requests that this Board please read the application and 
correspondence and move this case forward. 

Extremely frustrated, 

Alan Heimlich 

Historical prosecution history 

For the benefit of the board, the claims and the historical prosecution history of the 
instant application are illustrated on the following page. Claim structure is illustrated by 
indentation of the claims. Leftmost claims are independent. (I.e. claim 2 is dependent on 
claim 1, as is claim 3. Claim 5 is dependent on 4, which is dependent on 3, which is 
dependent on 1.) 

Each claim is addressed below, however. Claim 1 is considered particularly relevant 
because the dependent claims and other independent claims and dependent claims are 
variations on claim 1 . 
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INTRODUCTION 

The present invention relates to a lightweight end-to-end network architecture in 
which the transport layer is a Transmission Control Protocol (TCP) layer is disclosed. The 
network architecture also includes a Hyper Text Transport Protocol (HTTP) layer, a 
Messages over TCP (MT) protocol layer, a Message over Device-initiated HTTP (MDH) 
protocol layer, a multiplexing layer, and a facility layer. The MDH and MT layers are used in 
the alternative. The MT layer has a low overhead requirement. The MDH layer provides an 
enhanced firewall traversal capability. 
// 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 

Fourth Office - Claim 1 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 1 recites: 
1 . A computer network architecture comprising: 

a first layer including a transmission control protocol connection; 

a second layer including a hyper text transfer protocol connection built upon the first 

layer; 

a first tunneling layer including a first tunneling protocol built upon the second layer to 
tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer to multiplex a plurality of messages for transmission through the 
first tunneling layer. 
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Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 
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Tliirdiv , 

Applicant submits tliat tlie Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 

Fourthly , 

Assuming arguendo that Applicant's "a fist layer" is the same as OSI Layer 1 , the 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol ...". As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 
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Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 1 

Applicant for the reasons detailed above submits that Applicant's claim 1 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for independent claim 1 and allowance of claim 1 . 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 

Fifth Answer - Claim 1 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 1 recites: 
1 . A computer network architecture comprising: 

a first layer including a transmission control protocol connection; 

a second layer including a hyper text transfer protocol connection built upon the first 

layer; 

a first tunneling layer including a first tunneling protocol built upon the second layer to 
tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer to multiplex a plurality of messages for transmission through the 
first tunneling layer. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 
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Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
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decided witliout explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
Fifthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd lines ." (Page 1 Hne 16 to Page 2 line 3.) (EmphasiS added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 
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implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user. 
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but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 1 

Applicant for the reasons detailed above submits that Applicant's claim 1 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for independent claim 1 and allowance of claim 1 . 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 2 Rejection under 35 U.S.C. ^101 

Applicant's claim 2 recites: 

2. The computer network architecture of claim 1 , wherein the first tunneling protocol 
opens the hyper text transfer protocol connection between a server and a client . 
(Emphases added.) 



Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 2 

Applicant for the reasons detailed above submits that Applicant's claim 2 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 2 and allowance of claim 2. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 

Fifth Answer - Claim 2 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 2 recites: 

2. The computer network architecture of claim 1 , wherein the first tunneling protocol 
opens the hyper text transfer protocol connection between a server and a client . 

(Emphases added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 37 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 2 

Applicant for the reasons detailed above submits that Applicant's claim 2 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 2 and allowance of claim 2. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 3 Rejection under 35 U.S.C. ^101 

Applicant's claim 3 recites: 

3. The computer network architecture of claim 1 , further comprising: 

a second tunneling layer including a second tunneling protocol built upon the first 
layer to tunnel a message through the transmission control protocol connection. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 3 

Applicant for the reasons detailed above submits that Applicant's claim 3 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 3 and allowance of claim 3. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 3 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 3 recites: 

3. The computer network architecture of claim 1 , further comprising: 

a second tunneling layer including a second tunneling protocol built upon the first 
layer to tunnel a message through the transmission control protocol connection. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 3 

Applicant for the reasons detailed above submits that Applicant's claim 3 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 3 and allowance of claim 3. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 4 Rejection under 35 U.S.C. ^101 

Applicant's claim 4 recites: 

4. The computer network architecture of claim 3, wherein the second tunneling protocol 
is used to open the transmission control protocol connection between the server and the 
client . 

(Emphases added.) 
Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 



Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 



Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 
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Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 4 

Applicant for the reasons detailed above submits that Applicant's claim 4 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 4 and allowance of claim 4. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 54 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 



Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 4 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 4 recites: 

4. The computer network architecture of claim 3, wherein the second tunneling protocol 
is used to open the transmission control protocol connection between the server and the 
client . 

(Emphases added.) 
Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
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Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
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thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 4 

Applicant for the reasons detailed above submits that Applicant's claim 4 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 4 and allowance of claim 4. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 5 Rejection under 35 U.S.C. ^101 

Applicant's claim 5 recites: 

5. The computer network architecture of claim 4, wherein the first tunneling protocol 
opens the hyper text transfer protocol connection if the second tunneling protocol is not 
successful in opening the transmission control protocol connection. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 5 

Applicant for the reasons detailed above submits that Applicant's claim 5 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 5 and allowance of claim 5. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 5 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 5 recites: 

5. The computer network architecture of claim 4, wherein the first tunneling protocol 
opens the hyper text transfer protocol connection if the second tunneling protocol is not 
successful in opening the transmission control protocol connection. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 5 

Applicant for the reasons detailed above submits that Applicant's claim 5 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 5 and allowance of claim 5. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 6 Rejection under 35 U.S.C. ^101 

Applicant's claim 6 recites: 

6. The computer network of claim 1 , wherein the messages include binary format 
messages. 



Firsth 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 6 

Applicant for the reasons detailed above submits that Applicant's claim 6 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 6 and allowance of claim 6. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 74 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 



Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 6 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 6 recites: 

6. The computer network of claim 1 , wherein the messages include binary format 

messages. 

(Emphasis added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 77 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly, 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 6 

Applicant for the reasons detailed above submits that Applicant's claim 6 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 6 and allowance of claim 6. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 7 Rejection under 35 U.S.C. ^101 

Applicant's claim 7 recites: 

7. The computer network architecture of claim 1 , wherein the plurality of messages 
includes a plurality of operational messages and a plurality of administrative messages. 
(Emphasis added.) 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 7 

Applicant for the reasons detailed above submits that Applicant's claim 7 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 7 and allowance of claim 7. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 7 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 7 recites: 

7. The computer network architecture of claim 1 , wherein the plurality of messages 
includes a plurality of operational messages and a plurality of administrative messages. 
(Emphasis added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly, 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 7 

Applicant for the reasons detailed above submits that Applicant's claim 7 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 7 and allowance of claim 7. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 8 Rejection under 35 U.S.C. ^101 

Applicant's claim 8 recites: 

8. The computer network architecture of claim 7, wherein the operational messages 
include operational data. 
(Emphasis added.) 



Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 



Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 



Thirdly , 
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Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 

Fourthly , 

Assuming arguendo that Applicant's "a fist layer" is the same as OSI Layer 1 , the 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol ...". As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 



Seventhly , 
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The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 8 

Applicant for the reasons detailed above submits that Applicant's claim 8 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 8 and allowance of claim 8. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 8 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 8 recites: 

8. The computer network architecture of claim 7, wherein the operational messages 
include operational data. 
(Emphasis added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly, 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 8 

Applicant for the reasons detailed above submits that Applicant's claim 8 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 8 and allowance of claim 8. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 9 Rejection under 35 U.S.C. ^101 

Applicant's claim 9 recites: 

9. The computer network architecture of claim 7, wherein the administrative messages 
can be selected from the group consisting of debug messages, firmware update messages 
and parameter configuration messages. 
(Emphasis added.) 



Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 
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Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 
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Tliirdiv , 

Applicant submits tliat tlie Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 

Fourthly , 

Assuming arguendo that Applicant's "a fist layer" is the same as OSI Layer 1 , the 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol ...". As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 
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Seventhly, 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 9 

Applicant for the reasons detailed above submits that Applicant's claim 9 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 9 and allowance of claim 9. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 104 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 



Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 9 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 9 recites: 

9. The computer network architecture of claim 7, wherein the administrative messages 
can be selected from the group consisting of debug messages, firmware update messages 
and parameter configuration messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 1 recites among 
other things "A computer network architecture" as such the architecture has a tangible 
element a computer. Even one not of ordinary skill in the art knows that a computer network 
architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly, 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 9 

Applicant for the reasons detailed above submits that Applicant's claim 9 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 8 and allowance of claim 9. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 10 Rejection under 35 U.S.C. ^101 

Applicant's claim 10 recites: 

1 0. A method for a computer network architecture comprising: 

building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the hyper text transfer protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the hyper text transfer 
protocol connection by using a multiplexing layer. 

(Emphasis added.) 
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Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 
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Tliirdiv , 

Applicant submits tliat tlie Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 

Fourthly , 

Assuming arguendo that Applicant's "a fist layer" is the same as OSI Layer 1 , the 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol ...". As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 113 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 10 

Applicant for the reasons detailed above submits that Applicant's claim 10 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for independent claim 10 and allowance of claim 10. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 10 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 10 recites: 

1 0. A method for a computer network architecture comprising: 

building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the hyper text transfer protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the hyper text transfer 
protocol connection by using a multiplexing layer. 

(Emphasis added.) 



Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 
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Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
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decided witliout explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
Fifthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd lines ." (Page 1 Hne 16 to Page 2 line 3.) (EmphasiS added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 
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implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user. 
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but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 10 

Applicant for the reasons detailed above submits that Applicant's claim 10 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 10 and allowance of claim 10. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 11 Rejection under 35 U.S.C. ^101 

Applicant's claim 1 1 recites: 

1 1 . The method of claim 1 0, wherein opening the hyper text transfer protocol connection 
between a server and a client by using the first tunneling layer. 
(Emphasis added.) 



Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 123 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 1 1 

Applicant for the reasons detailed above submits that Applicant's claim 1 1 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 1 1 and allowance of claim 1 1 . 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

I. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 

Fifth Answer - Claim 11 Rejection under 35 U.S.C. ^101 

Applicant's claim 1 1 recites: 

I I . The method of claim 1 0, wherein opening the hyper text transfer protocol connection 
between a server and a client by using the first tunneling layer. 

(Emphasis added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 1 1 

Applicant for the reasons detailed above submits that Applicant's claim 1 1 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 1 1 and allowance of claim 1 1 . 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 12 Rejection under 35 U.S.C. ^101 

Applicant's claim 12 recites: 

1 2. The method of claim 1 0, further comprising: 

tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
transmission control protocol connection. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 



Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 



Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 



The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 



Fifth h 



Sixth h 



Seventhly , 
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Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 12 

Applicant for the reasons detailed above submits that Applicant's claim 12 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 12 and allowance of claim 12. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 12 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 12 recites: 

1 2. The method of claim 1 0, further comprising: 

tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
transmission control protocol connection. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
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tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 12 

Applicant for the reasons detailed above submits that Applicant's claim 12 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 12 and allowance of claim 12. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 13 Rejection under 35 U.S.C. ^101 

Applicant's claim 13 recites: 

13. The method of claim 12, wherein opening the transmission control protocol 
connection between a server and a client by using the second tunneling protocol. 
(Emphases added.) 



Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 13 

Applicant for the reasons detailed above submits that Applicant's claim 13 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 13 and allowance of claim 13. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 

Fifth Answer - Claim 13 Rejection under 35 U.S.C. ^101 

Applicant's claim 13 recites: 

13. The method of claim 12, wherein opening the transmission control protocol 
connection between a server and a client by using the second tunneling protocol. 
(Emphases added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 13 

Applicant for the reasons detailed above submits that Applicant's claim 13 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 13 and allowance of claim 13. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 14 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 14 recites: 

14. The method of claim 13, wherein opening the hyper text transfer protocol connection 
by using the first tunneling protocol if the transmission control protocol connection is not 
successfully opened by using the second tunneling protocol. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 14 

Applicant for the reasons detailed above submits that Applicant's claim 14 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 14 and allowance of claim 14. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 14 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 14 recites: 

14. The method of claim 13, wherein opening the hyper text transfer protocol connection 
by using the first tunneling protocol if the transmission control protocol connection is not 
successfully opened by using the second tunneling protocol. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 156 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 14 

Applicant for the reasons detailed above submits that Applicant's claim 14 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 14 and allowance of claim 14. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 15 Rejection under 35 U.S.C. ^101 

Applicant's claim 15 recites: 
1 5. The method of claim 1 0, wherein the messages include binary format messages. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 15 

Applicant for the reasons detailed above submits that Applicant's claim 15 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 15 and allowance of claim 15. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 15 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 15 recites: 
1 5. The method of claim 1 0, wherein the messages include binary format messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 167 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 15 

Applicant for the reasons detailed above submits that Applicant's claim 15 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 15 and allowance of claim 15. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 16 Rejection under 35 U.S.C. ^101 

Applicant's claim 16 recites: 

16. The method of claim 10, wherein the plurality of messages include a plurality of 
operational messages and a plurality of administrative messages. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 16 

Applicant for the reasons detailed above submits that Applicant's claim 16 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 16 and allowance of claim 16. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 16 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 16 recites: 

16. The method of claim 10, wherein the plurality of messages include a plurality of 
operational messages and a plurality of administrative messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 16 

Applicant for the reasons detailed above submits that Applicant's claim 16 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 16 and allowance of claim 16. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 17 Rejection under 35 U.S.C. ^101 

Applicant's claim 17 recites: 
17. The method of claim 16, wherein the operational messages include operational data. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 17 

Applicant for the reasons detailed above submits that Applicant's claim 17 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 17 and allowance of claim 17. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 17 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 17 recites: 
17. The method of claim 16, wherein the operational messages include operational data. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 17 

Applicant for the reasons detailed above submits that Applicant's claim 17 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 17 and allowance of claim 17. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 18 Rejection under 35 U.S.C. ^101 

Applicant's claim 18 recites: 

18. The method of claim 16, wherein the administrative messages can be selected from 
the group consisting of debug messages, firmware update messages and parameter 
configuration messages. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 18 

Applicant for the reasons detailed above submits that Applicant's claim 18 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 18 and allowance of claim 18. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 18 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 18 recites: 

18. The method of claim 16, wherein the administrative messages can be selected from 
the group consisting of debug messages, firmware update messages and parameter 
configuration messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 10 recites 
among other things "a computer network architecture" as such the architecture uses a 
tangible element a computer. Even one not of ordinary skill in the art knows that a computer 
network architecture uses computers. Computers are not an abstract idea. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer. A computer 
is a tangible thing and not an abstract idea. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and thus a computer network architecture as 
Applicant has claimed is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that "The 

layers can be implemented either in hardware or software." (Page 1, lines 6-7.) Neither hardware nor 

software are an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the first layer is not an abstract idea and the Examiner has 
failed to provide any evidence of such. Rather Applicant suspects that the Examiner has 
decided without explicitly stating so to classify Applicant's "first layer" as some sort of 
abstraction in the Examiner's mind. Applicant's specification is quite clear in stating that 

"Figure 1 illustrates a network architecture . . . each layer passes (or tunnels) data and control information to 
the layer immediately below it . . . The virtual communication is shown by dotted lines and the physical 
communication by sohd hnes ." (Page 1 Hne 16 to Page 2Hne 3.) (Emphasis added.) Physical 

communication by a layer is not an abstract idea. 
Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
these additional layers are not an abstract idea and the Examiner has failed to provide any 
evidence of such. Rather Applicant suspects that the Examiner has decided without 
explicitly stating so to classify all of Applicant's "layers" as some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither hardware nor Software are 

an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that 
these layers are not an abstract idea and the Examiner has failed to provide any evidence of 
such. The Examiner without any basis has decided to classify Applicant's "layers" as some 
sort of abstraction for which the Examiner provides no basis or case law. Applicant's 

specification is quite clear in stating that "Figure l illustrates a network architecture ... each layer 
passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page 2 line 3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 18 

Applicant for the reasons detailed above submits that Applicant's claim 18 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 18 and allowance of claim 18. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 

Fourth Office - Claim 19 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 19 recites: 

1 9. A computer readable medium having instructions which, when executed by a 
processing system , cause the system to perform a method comprising: 

building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the Hyper Text Transfer Protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the Hyper Text Transfer 
Protocol connection by using a multiplexing layer. 
(Emphases added.) 
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Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 
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Tliirdiv , 

Applicant submits tliat tlie Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 

Fourthly , 

Assuming arguendo that Applicant's "a fist layer" is the same as OSI Layer 1 , the 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol ...". As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 
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Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 19 

Applicant for the reasons detailed above submits that Applicant's claim 19 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 19 and allowance of claim 19. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 204 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 



Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 19 Rejection under 35 U.S.C. ^101 

Applicant's claim 19 recites: 

1 9. A computer readable medium having instructions which, when executed by a 
processing system , cause the system to perform a method comprising: 

building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the Hyper Text Transfer Protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the Hyper Text Transfer 
Protocol connection by using a multiplexing layer. 
(Emphases added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 
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Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 
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Fourtlilv, 

Tlie Examiner lias COncluSOry stated tliat "a first layer ... were abstract 

idea . " Applicant submits tliat a computer readable medium is not an abstract idea and tlie 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 

Fifthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 
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Sixthly, 

The Examiner has conciusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
Seventhly, 

The Examiner has conciusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
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Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 
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Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 
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Fifth Answer - In Summary - Claim 19 

Applicant for the reasons detailed above submits that Applicant's claim 19 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 19 and allowance of claim 19. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 20 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 20 recites: 

20. The medium of claim 19, wherein opening the Hyper Text Transfer Protocol 
connection between a server and a client by using the first tunneling layer. 
(Emphases added.) 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 213 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 20 

Applicant for the reasons detailed above submits that Applicant's claim 20 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 20 and allowance of claim 20. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 20 Rejection under 35 U.S.C. ^101 

Applicant's claim 20 recites: 

20. The medium of claim 19, wherein opening the Hyper Text Transfer Protocol 
connection between a server and a client by using the first tunneling layer. 
(Emphases added.) 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 



Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
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a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
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thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 



Fifth Answer - In Summary - Claim 20 
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Applicant for the reasons detailed above submits that Applicant's claim 20 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 20 and allowance of claim 20. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 21 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 21 recites: 

21 . The medium of claim 1 9, further comprising: 

tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
Transmission Control Protocol Connection. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 



Firsth 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 



Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 



Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 



Seventhly , 
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The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 

Eighthly , 

Regarding the Office's contention "Examiner can not det ermine without 
undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 21 

Applicant for the reasons detailed above submits that Applicant's claim 21 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 21 and allowance of claim 21 . 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 20 Rejection under 35 U.S.C. ^101 

Applicant's claim 21 recites: 

21 . The medium of claim 1 9, further comprising: 

tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
Transmission Control Protocol Connection. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
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readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 
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specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 

Fifthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
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single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 
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Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth ly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 
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Fifth Answer - In Summary - Claim 21 

Applicant for the reasons detailed above submits that Applicant's claim 21 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 21 and allowance of claim 21 . 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 22 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 22 recites: 

22. The medium of claim 21 , wherein opening the Transmission Control Protocol 
connection between a server and a client by using the second tunneling protocol. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 22 

Applicant for the reasons detailed above submits that Applicant's claim 22 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 22 and allowance of claim 22. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 22 Rejection under 35 U.S.C. ^101 

Applicant's claim 22 recites: 

22. The medium of claim 21 , wherein opening the Transmission Control Protocol 
connection between a server and a client by using the second tunneling protocol. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 



Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 



Ninthly, 
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Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 
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Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 



Fifth Answer - In Summary - Claim 22 
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Applicant for the reasons detailed above submits that Applicant's claim 22 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 22 and allowance of claim 22. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 23 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 23 recites: 

23. The medium of claim 22, wherein opening the Hyper Text Transfer Protocol 
connection by using the first tunneling protocol if the Transmission Control Protocol 
connection is not successfully opened by using the second tunneling protocol. 

Firstly , 

The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 
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The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 23 

Applicant for the reasons detailed above submits that Applicant's claim 23 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 23 and allowance of claim 23. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 23 Rejection under 35 U.S.C. ^101 

Applicant's claim 23 recites: 

23. The medium of claim 22, wherein opening the Hyper Text Transfer Protocol 
connection by using the first tunneling protocol if the Transmission Control Protocol 
connection is not successfully opened by using the second tunneling protocol. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant's claim clearly notes a server and a client. As such the claim is directed to 
patentable statutory subject matter. A physical server and a physical client are not an 
abstract idea. 



Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
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a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Tenthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.3d 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Eleventhly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
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thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Twelfth Iv , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 



Fifth Answer - In Summary - Claim 23 
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Applicant for the reasons detailed above submits that Applicant's claim 23 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 23 and allowance of claim 23. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 24 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 24 recites: 
24. The medium of claim 1 9, wherein the messages include binary format messages. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 



Firsth 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 24 

Applicant for the reasons detailed above submits that Applicant's claim 24 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 24 and allowance of claim 24. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 24 Rejection under 35 U.S.C. ^101 

Applicant's claim 24 recites: 
24. The medium of claim 1 9, wherein the messages include binary format messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 24 

Applicant for the reasons detailed above submits that Applicant's claim 19 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 24 and allowance of claim 24. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 25 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 25 recites: 

25. The medium of claim 19, wherein the plurality of messages include a plurality of 
operational messages and a plurality of administrative messages. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 25 

Applicant for the reasons detailed above submits that Applicant's claim 25 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 25 and allowance of claim 25. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 25 Rejection under 35 U.S.C. ^101 

Applicant's claim 25 recites: 

25. The medium of claim 19, wherein the plurality of messages include a plurality of 
operational messages and a plurality of administrative messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 25 

Applicant for the reasons detailed above submits that Applicant's claim 25 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 25 and allowance of claim 25. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 



Fourth Office - Claim 26 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 26 recites: 
26. The medium of claim 25, wherein the operational messages include operational data. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 



Firsth 
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For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 277 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 26 

Applicant for the reasons detailed above submits that Applicant's claim 26 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 26 and allowance of claim 26. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 26 Rejection under 35 U.S.C. ^101 

Applicant's claim 26 recites: 
26. The medium of claim 25, wherein the operational messages include operational data. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 
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Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 

specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 
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Fifthly, 

The Examiner has COnciuSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
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Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid lines ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 
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Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 

Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 
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Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 26 

Applicant for the reasons detailed above submits that Applicant's claim 26 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 26 and allowance of claim 26. 
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Fourth Office - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at 3 states: 

3. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. It was well- 
known in the network art that the first layer is the physical layer and 
the second layer is link layer. It was unclear if the applicant 
claimed the first layer is TCP and the second layer is HTTP then the 
network architecture, as claimed, without using the physical layer and 
link layer is impossible to communication. Examiner can not determine 
what applicant intended scope and Examiner can not determine without 
undue experimentation. 

Fourth Office - Claim 27 Rejection under 35 U.S.C. ^ 101 

Applicant's claim 27 recites: 

27. The medium of claim 25, wherein the administrative messages can be selected from 
the group consisting of debug messages, firmware update messages and parameter 
configuration messages. 



The Office states: "it was well-known in the network art that the first 
layer is the physical layer and the second layer is link layer." 

Applicant submits that the Examiner is referring to an artificial model created for easy 
discussion rather than what Applicant has claimed. 



Firsth 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 286 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

The Examiner's reasoning is flawed as it arbitrarily makes distinctions and 
assumptions that are not relevant and are not what Applicant disclosed. 

For example, the statement "...the network architecture, as claimed, 
without using the physical layer and link layer is impossible to 
communication. " is irrelevant to what the Applicant has claimed. The Examiner could 
also argue "that without the physical connector to a communications channel, 
communication is impossible." While both statements may be true they are not germane to 
what Applicant has claimed. 

Secondly , 

One of skill in the network arts is familiar with both the ISO/OSI Network Model and 
the TCP/IP Network Model. As one of skill in the art is well aware, the TCP/IP Network 
Model has a link layer 1 on top of a network layer 2. The TCP/IP Network Model DOES 
NOT have a "physical layer". The Examiner's arguments with respect to a "physical layer" 
are immaterial to what the Applicant has claimed. Applicant is not claiming either of these 
models. Applicant submits that the Examiner is trying to "force fit" what Applicant has 
claimed into an existing network model to support a basis for rejection rather than 
understanding what the Applicant has claimed. 

Thirdly , 

Applicant submits that the Examiner is equating Applicant's "a first layer" to an OSI 
Layer 1 . Applicant has never stated such in the application. 
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Fourtlilv , 

Assuming arguendo that Applicant's "a fist layer" is tlie same as OSI Layer 1 , tlie 
argument makes no sense since Applicant clearly states "a first layer including a 
transmission control protocol As the Examiner should be aware OSI Layer 1 is only a 
physical layer and does not include a TCP. 

Fifthly , 

Applicant submits that the Examiner is equating Applicant's "a second layer" to an 
OSI Layer 2. Applicant has never stated such in the application. 

Sixthly , 

Assuming arguendo that Applicant's "a second layer" is the same as OSI Layer 2, the 
argument makes no sense since Applicant clearly states "a second layer including a hyper 
text transfer protocol ...". As the Examiner should be aware OSI Layer 2 is only a data link 
layer and does not include a HTTP. 

Seventhly , 

The Office then states: "Examiner can not determine what applicant 
intended scope and Examiner can not determine without undue 
experimentation. " 

Applicant submits that the claims clearly define the invention and that the 
specification clearly describes and shows via the many figures the scope of the invention. 
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Eighthly , 

Regarding the Office's contention "Examiner can not determine without 

undue experimentation." Applicant most Strongly disagrees. 

The specification and figures clearly show and describe embodiments of the invention 
as well as examples of usage. One skilled in the network arts can easily ascertain from, for 
example. Figure 2, the various layers and from the specification the interactions as well as 
the other Figures, such as Figure 5, the communications exchanges. There is no "undue 
experimentation" required to ascertain what the invention is or what Applicant has claimed. 

Fourth Office - In Summary - Claim 27 

Applicant for the reasons detailed above submits that Applicant's claim 27 is directed 
to statutory matter. Applicant respectfully requests removal of the 35 U.S.C. § 101 rejection 
for claim 27 and allowance of claim 27. 
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Fifth Answer - Claims 1- 27 Rejection under 35 U.S.C. ^ 101 

The Office at (9) Page 3 states: 

1. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter, (i.e.: a first 
layer, second layer, multiplexing layer and tunneling layer were 
abstract idea) . 



Fifth Answer - Claim 27 Rejection under 35 U.S.C. ^101 

Applicant's claim 27 recites: 

Applicant's claim 27 recites: 

27. The medium of claim 25, wherein the administrative messages can be selected from 
the group consisting of debug messages, firmware update messages and parameter 
configuration messages. 

Firstly , 

The Office states: "a first layer, second layer, multiplexing 
layer and tunneling layer were abstract idea." 

Applicant submits that the Examiner is selectively clipping words and stating without 
support a conclusion. This would be no different than the examiner clipping the words "first" 
and "second" and then stating these are an abstract idea. Applicant's claim 19 recites 
among other things " computer readable medium " and " a processing system " as such the 
apparatus has tangible entities. Even an ordinary lay person knows that a computer 
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readable medium (e.g. floppy, flash drive, etc.) is a tangible medium. A computer readable 
medium and a processing system are not abstract ideas. 

Secondly , 

While limitations in the specification may not be read into the claims, the specification 
may be used to explain terms. Applicant's Figure 10 clearly shows a computer (an example 
of a processing system). Applicant's Figure 10 clearly shows a computer readable medium 
(e.g. RAM, ROM, Storage, etc.). A computer readable medium and a processing system 
are not abstract ideas. 

Thirdly , 

Applicant's Figure 7 clearly shows a network architecture 200 on a server 410, and a 
network architecture 200 on a client 420. Servers and clients are well known to have 
physical embodiments utilizing a computer and are examples of processing systems which 
is a physical tangible entity and not an abstract idea. 

Fourthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that a computer readable medium is not an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's computer readable 
medium as a "first layer" and some sort of abstraction in the Examiner's mind. Applicant's 
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specification is quite clear in stating that "The layers can be implemented either in hardware or 

software." (Page 1, Hnes 6-7.) Neither a computer readable medium nor a processing system are 
an abstract idea. 

Fifthly, 

The Examiner has COncluSOry stated that "a first layer ... were abstract 

idea . " Applicant submits that the computer readable medium r is not an abstract idea and 
the Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify Applicant's a computer 
readable medium is a "first layer" and some sort of abstraction in the Examiner's mind. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Neither a computer readable medium nor a processing 
system are an abstract idea. 

Sixthly, 

The Examiner has conclusory stated that ". . .second layer, multiplexing 
layer and tunneling layer ... were abstract idea." Applicant submits that 
neither a computer readable medium nor a processing system are an abstract idea and the 
Examiner has failed to provide any evidence of such. Rather Applicant suspects that the 
Examiner has decided without explicitly stating so to classify all of Applicant's computer 
readable medium and processing system as "layers" ane some sort of abstraction without a 
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single basis in fact. Applicant's specification is quite clear in stating that "The layers can be 

implemented either in hardware or software." (Page 1, Hnes 6-7.) Neither a Computer readable 

medium nor a processing system are an abstract idea. 
Seventhly, 

The Examiner has conclusory stated that "...second layer, multiplexing 
layer and tunneling layer... were abstract idea." Applicant submits that a 
computer readable medium and a processing system are not an abstract idea and the 
Examiner has failed to provide any evidence of such. The Examiner without any basis has 
decided to classify Applicant's computer readable medium and processing system as 
"layers" and some sort of abstraction for which the Examiner provides no basis or case law. 

Applicant's specification is quite clear in stating that "Figure l illustrates a network architecture ... 
each layer passes (or tunnels) data and control information to the layer immediately below it . . . The virtual 
communication is shown by dotted lines and the physical communication by solid hnes ." (Page 1 Hne 16 to 

Page2Hne3.) (Emphasis added.) Physical communication by a layer is not an abstract idea. 
Eighthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106 regarding patent subject matter eligibility. Applicant submits that the claimed 
invention as a whole is useful and accomplishes a practical application. That is, it produces 
a "useful, concrete and tangible result." See State Street Bank & Trust Co. v. Signature 
Financial Group Inc., 149 F.3d 1368, 1373-74, 47 USPQ2d 1596, 1601-02 (Fed. Cir. 1998). 
For example Applicant details in the specification not only communications that produce a 
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useful, concrete and tangible result, for example on a display (Figure 10 at 1020) for a user, 
but also other useful, concrete and tangible results, such as, but not limited to, physical pin 
manipulation (see Figure 9). 

Ninthly, 

Applicant submits that the Examiner has failed to follow the guidelines as detailed in 
MPEP 2106. Per the MPEP: USPTO personnel are to correlate each claim limitation to all 
portions of the disclosure that describe the claim limitation and USPTO personnel are to 
give claims their broadest reasonable interpretation in light of the supporting disclosure. In 
re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). 
Additionally where an explicit definition is provided by the applicant for a term, that definition 
will control interpretation of the term as it is used in the claim. Toro Co. v. White 
Consolidated Industries Inc., 199 F.Sd 1295, 1301, 53 USPQ2d 1065, 1069 (Fed. Cir. 1999) 
(meaning of words used in a claim is not construed in a "lexicographic vacuum, but in the 
context of the specification and drawings."). Here Applicant has clearly defined "layers" as 
having a tangible physical entity and not as an abstract idea. 

Tenthly , 

Assuming arguendo, that Applicant's claim initially appears to be an "abstract idea", 
even then a claimed invention is directed to a practical application of a 35 U.S.C. 101 
judicial exception when it: (A) "transforms" an article or physical object to a different state or 
thing; or (B) otherwise produces a useful, concrete and tangible result, based on a physical 
transformation or that produces a useful, concrete, and tangible result. 
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Here Applicant has clearly shown that the invention produces a useful, concrete and 
tangible result. 

Eleventhly , 

The burden is on the USPTO to set forth a prima facie case of unpatentability. In re 
Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). If the record as a 
whole suggests that it is more likely than not that the claimed invention would be considered 
a practical application of an abstract idea, natural phenomenon, or law of nature, then 
USPTO personnel should not reject the claim. If USPTO personnel determine that it is more 
likely than not that the claimed subject matter falls outside all of the statutory categories, 
they must provide an explanation. 

Here the Examiner has failed to state why Applicant's claim is an abstract idea 
with no practical application. Applicant submits that the record as a whole suggests that at a 
minimum the claimed invention would be considered a practical application of an abstract 
idea and therefore overcomes the 35 USC 101 rejection. 

Fifth Answer - In Summary - Claim 27 

Applicant for the reasons detailed above submits that Applicant's claim 27 is directed 
to statutory matter. Applicant respectfully reguests removal of the 35 U.S.C. § 101 rejection 
for claim 27 and allowance of claim 27. 
//// 
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Fourth Office - Claim 1 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 4 states: 

4. As per claim 1, Bavadekar discloses a computer network 
architecture comprising: 

a first layer including a transmission control protocol 
connection [Bavadekar, TCP connection, 0050] ; 

a second layer including a hyper text transfer protocol 
connection built upon the first layer [Bavadelar, HTTP tunnel, 0050]; 

a first tunneling layer including a first tunneling protocol 
built upon the second layer to tunnel a message through the hyper text 
transfer protocol connection; and a multiplexing layer to multiplex a 
plurality of messages for transmission through the first tunneling 
layer [Bavadelar, HTTP tunnel may multiplex packets from the clients 
onto TCP connection, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 
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Applicant's claim 1 recites: 
1 . A computer network architecture comprising: 

a first layer including a transmission control protocol connection; 

a second layer including a hyper text transfer protocol connection built upon the first 

layer; 

a first tunneling layer including a first tunneling protocol built upon the second layer to 
tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer to multiplex a plurality of messages for transmission through the 
first tunneling layer. 

To better assist in the discussion that follows, Applicant has added the bolded 
bracketed notations to the first portion of Bavadekar paragraph [0050] to better illustrate the 
entities as may be seen in Bavadekar Figure 3B and bolded bracketed notations to 
Applicant's claim 1. 

[0050] In one embodiment, [see Figure 3B] one Web server [208] and one tunnel servlet [214] may 
be used by two or more clients [200A, 200B] to communicate to a broker [202] via tunnel 
connections. In this embodiment, the HTTP tunnel servlet [214] may multiplex transport protocol 
packets from the two or more clients [200A, 200B] onto the TCP connection [216]. In one 
embodiment, the tunnel servlet may extract the messaging system message information from received 
transport protocol packets and send only the message information to the broker over the TCP 
connection. In one embodiment, there may be one broker-side receive buffer for each tunnel 
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connection. In another embodiment, a single receive buffer may be used for two or more tunnel 
connections. 

(Emphases added.) 

Applicant's claim 1 recites: 

1 . A computer network architecture [see Figure 2] comprising: 

a first layer including a transmission control protocol connection [222]; 

a second layer including a hyper text transfer protocol connection [232] built upon the 

first layer [222]; 

a first tunneling layer including a first tunneling protocol [240] built upon the second 
layer [232] to tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer [270] to multiplex a plurality of messages for transmission 
through the first tunneling layer [240]. 
(Emphasis added.) 

Applicant submits that Bavadekar additionally discloses at [0074]: 

[0074] The HTTP tunnel client driver 220 may then send the messages as HTTP POST request 
payloads. The HTTP tunnel client driver 220 may also use separate HTTP requests to periodically 
pull any data sent by the other end of the connection. The HTTP requests may be sent through HTTP 
proxy 206, Internet 204, and firewall 210 to Web server 208. On Web server 208, the HTTP tunnel 
servlet 214 may act as a transceiver and may multiplex the HTTP requests from multiple clients onto 
a single TCP connection 216 with the broker 202. The HTTP tunnel broker driver 240 may receive 
the HTTP requests from the Web server 210 over TCP connection 216. 
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(Emphases added.) 

Thus Bavadekar discloses multiplexing the transport protocol packets [0050] or the 
HTTP requests [0074]. In either case the packets or requests are already arriving at the 
HTTP tunnel servlet 214 of Bavadekar as tunnel communications. Thus Bavadekar is 
multiplexing tunnel communications onto TCP 216. In contrast Applicant is multiplexing a 
plurality of messages into the tunneling which may then be transported via TCP. 

The illustration below indicates the difference. 



<r Multiplexing already 
tunneled communications 
onto TCP (Bavadekar) is 
not the same as 
multiplexing a plurality of 
messages into the 
tunneling which may then 
be transported via TCP 
^(Applicant). 
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Further, Bavadekar then discusses at [0050], "In one embodiment, the tunnel servlet may 
extract the messaging system message information from received transport protocol packets and send 
only the message information to the broker over the TCP connection ." 

(Emphases added.) 

This "teaches away" from the tunneling as disclosed by the Applicant. 

Applicant submits that the Examiner has failed to establish a prima facie rejection 
under 35 U.S.C. § 102(e) because "Anticipation requires the presence in a single prior art 
reference disclosure of each and every element of the claimed invention, arranged as in the 
claim." Lindemann Mascliinenfabrik GMBI-i v. American l-ioist & Derrick {"Lindemann"), 730 
F.2d 1452, 1458 (Fed. Cir. 1984) (emphasis added). Additionally, each and every element 
of the claim must be exactly disclosed in the anticipatory reference. Titanium Metals Corp. 
of America v. Banner, 778 F.2d 775, 777 (Fed. Cir. 1985). 

Applicant submits that because Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer that Bavadekar cannot anticipate 
what Applicant has claimed. Applicant respectfully requests allowance of independent claim 
1 , and claims 2-9 which are dependent on claim 1 . 
// 
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Fifth Answer - Claim 1 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 3-4 states: 

2. As per claim 1, Bavadekar discloses a computer network 
architecture comprising: 

a first layer including a transmission control protocol 
connection [Bavadekar, TCP connection, 0050] ; 

a second layer including a hyper text transfer protocol 
connection built upon the first layer [Bavadelar [sic] , HTTP tunnel, 
0050] ; 

a first tunneling layer including a first tunneling protocol 
built upon the second layer to tunnel a message through the hyper text 
transfer protocol connection [Bavadekar, HTTP tunnel broker driver 240; 
HTTP tunnel servlet 214, Fig 3B] ; and a multiplexing layer to multiplex 
a plurality of messages for transmission through the first tunneling 
layer [Bavadelar [sic] , HTTP tunnel may multiplex packets from the 
clients onto TCP connection, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 
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Applicant's claim 1 recites: 
1 . A computer network architecture comprising: 

a first layer including a transmission control protocol connection; 

a second layer including a hyper text transfer protocol connection built upon the first 

layer; 

a first tunneling layer including a first tunneling protocol built upon the second layer to 
tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer to multiplex a plurality of messages for transmission through the 
first tunneling layer. 

To better assist in the discussion that follows, Applicant has added the bolded 
bracketed notations to the first portion of Bavadekar paragraph [0050] to better illustrate the 
entities as may be seen in Bavadekar Figure 3B and bolded bracketed notations to 
Applicant's claim 1. 

[0050] In one embodiment, [see Figure 3B] one Web server [208] and one tunnel servlet [214] may 
be used by two or more clients [200A, 200B] to communicate to a broker [202] via tunnel 
connections. In this embodiment, the HTTP tunnel servlet [214] may multiplex transport protocol 
packets from the two or more clients [200A, 200B] onto the TCP connection [216]. In one 
embodiment, the tunnel servlet may extract the messaging system message information from received 
transport protocol packets and send only the message information to the broker over the TCP 
connection. In one embodiment, there may be one broker-side receive buffer for each tunnel 
connection. In another embodiment, a single receive buffer may be used for two or more tunnel 
connections. 
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(Emphases added.) 

Applicant's claim 1 recites: 

1 . A computer network architecture [see Figure 2] comprising: 

a first layer including a transmission control protocol connection [222]; 

a second layer including a hyper text transfer protocol connection [232] built upon the 

first layer [222]; 

a first tunneling layer including a first tunneling protocol [240] built upon the second 
layer [232] to tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer [270] to multiplex a plurality of messages for transmission 
through the first tunneling layer [240]. 
(Emphasis added.) 

Applicant submits that Bavadekar additionally discloses at [0074]: 

[0074] The HTTP tunnel client driver 220 may then send the messages as HTTP POST request 
payloads. The HTTP tunnel client driver 220 may also use separate HTTP requests to periodically 
pull any data sent by the other end of the connection. The HTTP requests may be sent through HTTP 
proxy 206, Internet 204, and firewall 210 to Web server 208. On Web server 208, the HTTP tunnel 
servlet 214 may act as a transceiver and may multiplex the HTTP requests from multiple clients onto 
a single TCP connection 216 with the broker 202. The HTTP tunnel broker driver 240 may receive 
the HTTP requests from the Web server 210 over TCP connection 216. 

(Emphases added.) 
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Thus Bavadekar discloses multiplexing the transport protocol packets [0050] or the 
HTTP requests [0074]. In either case the packets or requests are already arriving at the 
HTTP tunnel servlet 214 of Bavadekar as tunnel communications. Thus Bavadekar is 
multiplexing tunnel communications onto TCP 216. In contrast Applicant is multiplexing a 
plurality of messages into the tunneling which may then be transported via TCP. 



The illustration below indicates the difference. 
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<r Multiplexing already 
tunneled communications 
onto TCP (Bavadekar) is 
not the same as 
multiplexing a plurality of 
messages into the 
tunneling which may then 
be transported via TCP 
^(Applicant). 
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Further, Bavadekar then discusses at [0050], "In one embodiment, the tunnel servlet may 
extract the messaging system message information from received transport protocol packets and send 
only the message information to the broker over the TCP connection ." 

(Emphases added.) 

This " teaches away " from the tunneling as disclosed by the Applicant. 

Applicant submits that the Examiner has failed to establish a prima facie rejection 
under 35 U.S.C. § 102(e) because "Anticipation requires the presence in a single prior art 
reference disclosure of each and every element of the claimed invention, arranged as in the 
claim." Lindemann Mascliinenfabrik GMBI-i v. American l-ioist & Derrick {"Lindemann"), 730 
F.2d 1452, 1458 (Fed. Cir. 1984) (emphasis added). Additionally, each and every element 
of the claim must be exactly disclosed in the anticipatory reference. Titanium Metals Corp. 
of America v. Banner, 778 F.2d 775, 777 (Fed. Cir. 1985). 

Applicant submits that because Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer that Bavadekar cannot anticipate 
what Applicant has claimed. Applicant respectfully requests allowance of independent claim 
1 , and claims 2-9 which are dependent on claim 1 . 
// 
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Fourth Office - Claim 2 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 5 states: 

5. As per claim 2, Bavadekar discloses the first tunneling protocol 
(i.e.: TCP) opens the HTTP connection between a server and a client 
[Bavadekar, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections . In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection . In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 

(Emphases added.) 

Applicant's claim 2 recites: 

2. The computer network architecture of claim 1 , wherein the first tunneling protocol 
opens the hyper text transfer protocol connection between a server and a client. 
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Firstly , 

Claim 2 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 2. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 2. Applicant 
respectfully requests allowance of claim 2. 

Secondly , 

Applicant submits that the Office is incorrect when stating: "Bavadekar discloses 
the first tunneling protocol ( i.e. : TCP ) " . (Emphasis added.) On the contrary, 
Bavadekar discloses only HTTP tunnel connections. Bavadekar does not disclose TCP to 
be a tunneling protocol. Bavadekar discloses TCP to be a connection (TCP Connection 
216). The significance of this will become apparent in later claims where the Office tries to 
assert that the TCP is the first tunnel and that HTTP is a second tunnel. 

Summary - claim 2 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 2. Applicant 
respectfully requests allowance of claim 2. 

// 
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Fifth Answer - Claim 2 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 4 states: 
The Office at 3. states: 

3. As per claim 2, Bavadekar discloses the first tunneling protocol 
(i.e.: TCP) opens the HTTP connection between a server and a client 
[Bavadekar, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections . In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection . In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 

(Emphases added.) 

Applicant's claim 2 recites: 

2. The computer network architecture of claim 1 , wherein the first tunneling protocol 
opens the hyper text transfer protocol connection between a server and a client. 
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Firstly , 

Claim 2 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 2. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 2. Applicant 
respectfully requests allowance of claim 2. 

Secondly , 

Applicant submits that the Office is incorrect when stating: "Bavadekar discloses 
the first tunneling protocol ( i.e. : TCP ) " . (Emphasis added.) On the contrary, 
Bavadekar discloses only HTTP tunnel connections. Bavadekar does not disclose TCP to 
be a tunneling protocol. Bavadekar discloses TCP to be a connection (TCP Connection 
216). The significance of this will become apparent in later claims where the Office tries to 
assert that the TCP is the first tunnel and that HTTP is a second tunnel. 

Summary - claim 2 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 2. Applicant 
respectfully requests allowance of claim 2. 

// 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 309 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 



Fourth Office - Claims 10-11. 19-20 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 6 states: 

6. Claims 10-11, 19-20 contain the similar limitations set forth of 
apparatus claims 1-2. Therefore, claims 10-11, 19-20 are rejected for 
the similar rationale set forth in claims 1-2. 



Applicant submits that with respect to claims 10-1 1 and 19-20, that as discussed 
above in the claim 1-2 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claims 10-1 1 and 19-20. Applicant respectfully requests allowance of 
independent claims 10, and 19, and claims 11-18 and 20-27 which are dependent upon 
independent claims 10 and 19 respectively. 

// 
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Fifth Answer - Claims 10-11. 19-20 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 4 states: 
The Office at 4. states: 

4. Claims 10-11, 19-20 contain the similar limitations set forth of 
apparatus claims 1-2. Therefore, claims 10-11, 19-20 are rejected for 
the similar rationale set forth in claims 1-2. 

Applicant submits that with respect to claims 10-1 1 and 19-20, that as discussed 
above in the claim 1-2 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claims 10-1 1 and 19-20. Applicant respectfully requests allowance of 
independent claims 10, and 19, and claims 11-18 and 20-27 which are dependent upon 
independent claims 10 and 19 respectively. 

// 
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Fourth Office - Claim 3 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 7 states: 

7. As per claim 3, Bavadekar discloses a second tunneling layer 
(i.e.: HTTP tunnel) including a second tunneling protocol (i.e.: HTTP 
protocol) built upon the first layer to tunnel a message through the 
TCP connection [Bavadekar, 0050] . 

(Emphasis added.) 

The cited reference states in part: [Bavadekar, 0 050] . 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 

Applicant's claim 3 recites: 

3. The computer network architecture of claim 1 , further comprising: 

a second tunneling layer including a second tunneling protocol built upon the first 
layer to tunnel a message through the transmission control protocol connection. 
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Applicant submits that Bavadekar does not disclose any second tunneling layer . The 

Office states: "Bavadekar discloses a second tunneling layer (i.e.: HTTP 
tunnel ) including a second tunneling protocol (i.e.: HTTP protocol) 
built upon the first layer to tunnel a message through the TCP 
connection [Bavadekar, 0050] ." 

(Emphasis added.) 
Firstly , 

Claim 3 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 3. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 3. Applicant 
respectfully requests allowance of claim 3. 

Secondly , 

As explained above (claim 2 - Secondly ), Bavadekar discloses only a single tunnel , 
that of the HTTP tunnel connections. Bavadekar does not disclose TCP to be a tunneling 
protocol. Bavadekar discloses TCP to be a connection (TCP Connection 216). Thus, 
Bavadekar does not disclose what Applicant has claimed ("a second tunneling layer"). 
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Thirdly , 

The Office statement is inconsistent. On the one hand, the Office is claiming the TCP 
to be a first tunnel, HTTP to be the second tunnel, and then wants to assert "to tunnel a 
message through the TCP connection ." (Emphasis added.) The Office cannot have 
the TCP as both a connection and tunnel. Since Bavadekar describes the TCP as a 
connection. Applicant submits that the Office is incorrect in characterizing the TCP as a 
tunnel. Reference is made to Bavadekar paragraph [0036] where tunneling is defined. 

Summary - claim 3 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 3. Applicant 
respectfully requests allowance of claim 3, and claims 4-5 which are dependent on claim 3. 
// 
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Fifth Answer - Claim 3 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 4 states: 

The Office at 5. states: 

5. As per claim 3, Bavadekar discloses a second tunneling layer 
(i.e.: HTTP tunnel) including a second tunneling protocol (i.e.: HTTP 
protocol) built upon the first layer to tunnel a message through the 
TCP connection [Bavadekar, 0050] . 

(Emphasis added.) 

The cited reference states in part: [Bavadekar, 0 050] . 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 

Applicant's claim 3 recites: 

3. The computer network architecture of claim 1 , further comprising: 

a second tunneling layer including a second tunneling protocol built upon the first 
layer to tunnel a message through the transmission control protocol connection. 
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Applicant submits that Bavadekar does not disclose any second tunneling layer . The 

Office states: "Bavadekar discloses a second tunneling layer (i.e.: HTTP 
tunnel ) including a second tunneling protocol (i.e.: HTTP protocol) 
built upon the first layer to tunnel a message through the TCP 
connection [Bavadekar, 0050] ." 

(Emphasis added.) 
Firstly , 

Claim 3 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 3. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 3. Applicant 
respectfully requests allowance of claim 3. 

Secondly , 

As explained above (claim 2 - Secondly ), Bavadekar discloses only a single tunnel , 
that of the HTTP tunnel connections. Bavadekar does not disclose TCP to be a tunneling 
protocol. Bavadekar discloses TCP to be a connection (TCP Connection 216). See 
Bavadekar at end of [0074]. Thus, Bavadekar does not disclose what Applicant has claimed 
("a second tunneling layer"). 
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Thirdly , 

The Office statement is inconsistent. On the one hand, the Office is claiming the TCP 
to be a first tunnel, HTTP to be the second tunnel, and then wants to assert "to tunnel a 
message through the TCP connection ." (Emphasis added.) The Office cannot 
have the TCP as both a connection and tunnel. Since Bavadekar describes the TCP as a 
connection (see Bavadekar [0074]), Applicant submits that the Office is incorrect in 
characterizing the TCP as a tunnel. Reference is made to Bavadekar paragraph [0036] 
where tunneling is defined. 

Summary - claim 3 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 3. Applicant 
respectfully requests allowance of claim 3, and claims 4-5 which are dependent on claim 3. 
// 
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Fourth Office - Claim 4 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 8 states: 

8. As per claim 4, Bavadekar- Puj are disclose the second tunneling 
protocol is used to open the TCP connection between the server and the 
client [Bavadekar, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 



Applicant's claim 4 recites: 
4. The computer network architecture of claim 3, wherein the second tunneling protocol 
is used to open the transmission control protocol connection between the server and the 
client. 
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Firstly , 

Claim 4 is dependent on claim 3 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 4. Further, Bavadekar cannot anticipate the further limitation of 
Applicant's claims 3 and 4. Applicant respectfully requests allowance of claim 4, and claim 
5 which is dependent on claim 4. 

Secondly , 

Nowhere in the cited section does Bavadekar disclose or discuss a second tunneling 
protocol as Applicant has claimed. Bavadekar only discusses a single tunnel protocol, that 
being an HTTP tunnel protocol (see Bavadekar Abstract - "A system and method for providing 
HTTP tunnel connections between entities such as clients and servers in a messaging system is 
described." (Emphasis added.) Since Bavadekar does not disclose a second tunneling 
protocol as Applicant has claimed, Bavadekar cannot anticipate Applicant's claim. 



Thirdly , 

Applicant notes that the Office mentions Pujare in paragraph 8. but cites no reference 
or argument. Applicant submits that Pujare does not anticipate the limitations of claim 1 or 
claim 4. 
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Summary - claim 4 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 4. Applicant 
respectfully requests allowance of claim 4, and claim 5 which is dependent on claim 4. 
// 
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Fifth Answer - Claim 4 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 
The Office at 6. states: 

6. As per claim 4, Bavadekar discloses the second tunneling protocol 
is used to open the TCP connection between the server and the client 
[Bavadekar, server-client, 0078] . 

The cited reference states: 

[0078] In one embodiment, when a connection is established between two entities or nodes (e.g. a 
server and client), each node may inform the other of how many packets it can initially receive. In a 
network, a node is a connection point, either a redistribution point or an end point for data 
transmissions. In general, a node has programmed or engineered capability to recognize, process 
and/or forward transmissions to other nodes. In one embodiment, each packet received by the receiver 
may be acknowledged with a packet sent to the sender. The acknowledgement packets may each 
include information indicating the current receive buffer size (i.e. the number of packets that the 
receiver can currently receive). Thus, the sender can determine the number of packets that it can send 
to the receiver without overwhelming the sender. 

Applicant's claim 4 recites: 
4. The computer network architecture of claim 3, wherein the second tunneling protocol 
is used to open the transmission control protocol connection between the server and the 
client. 
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Firstly , 

Claim 4 is dependent on claim 3 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 4. Further, Bavadekar cannot anticipate the further limitation of 
Applicant's claims 3 and 4. Applicant respectfully requests allowance of claim 4, and claim 
5 which is dependent on claim 4. 

Secondly , 

Nowhere in the cited section does Bavadekar disclose or discuss a second tunneling 
protocol as Applicant has claimed. Bavadekar only discusses a connection such as a server 
to a client and the exchange of information, for example "current receive buffer size." Since 
Bavadekar does not disclose a second tunneling protocol as Applicant has claimed , 
Bavadekar cannot anticipate Applicant's claim. 

Summary - claim 4 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 4. Applicant 
respectfully requests allowance of claim 4, and claim 5 which is dependent on claim 4. 
// 
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Fourth Office - Claim 5 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 9 states: 

9. As per claim 5, Bavadekar- Puj are disclose tunneling protocol 
opens the HTTP connection if the second tunneling protocol is not 
successful in opening the TCP connection [Bavadekar, 0050] . 

The cited reference states: 

[0050] In one embodiment, one Web server and one tunnel servlet may be used by two or more 
clients to communicate to a broker via tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex transport protocol packets from the two or more clients onto the TCP 
connection. In one embodiment, the tunnel servlet may extract the messaging system message 
information from received transport protocol packets and send only the message information to the 
broker over the TCP connection. In one embodiment, there may be one broker-side receive buffer for 
each tunnel connection. In another embodiment, a single receive buffer may be used for two or more 
tunnel connections. 

Applicant's claim 5 recites: 

5. The computer network architecture of claim 4, wherein the first tunneling protocol 
opens the hyper text transfer protocol connection if the second tunneling protocol is not 
successful in opening the transmission control protocol connection. 
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Firstly , 

Claim 5 is dependent on claim 4 which is dependent on claim 3 which is dependent 
on claim 1 , and as discussed above in the claim 1 discussion, Bavadekar fails to disclose 
multiplexing a plurality of messages for transmission through the first tunneling layer, 
therefore Bavadekar cannot anticipate Applicant's claim 5. Further, Bavadekar cannot 
anticipate the further limitation of Applicant's claims 3, 4, and 5. Applicant respectfully 
requests allowance of claim 5. 

Secondly , 

Nowhere in the cited section does Bavadekar disclose or discuss the condition where 
another protocol is tried if a first one is not successful (i.e. first protocol is attempted if a 
second protocol is not successful). Since Bavadekar does not disclose this limitation of 
Applicant's claim 5, Bavadekar cannot anticipate Applicant's claim. 

Thirdly , 

Applicant notes that the Office mentions Pujare in paragraph 9. but cites no reference 
or argument. Applicant submits that Pujare does not anticipate the limitations of claim 1 or 
claim 5. 

Summary - claim 5 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 5. Applicant 
respectfully requests allowance of claim 5. 
// 
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Fifth Answer - Claim 5 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 
The Office at 7. states: 

7. As per claim 5, Bavadekar discloses tunneling protocol opens the 
HTTP connection if the second tunneling protocol is not successful in 
opening the TCP connection [Bavadekar, exchange message, 0079] . 

The cited reference states: 

[0079] In one embodiment, the client 200, broker 202 and the messaging protocol layers 212 may 
function similarly whether the underlying transport protocol is TCP or HTTP. In one embodiment, 
the messaging protocol layers 212 on both the client and the broker may use the same basic design 
and threading model for TCP and HTTP support. In one embodiment, an enterprise messaging system 
using the HTTP tunneling protocol may allow a messaging system application to exchange messages 
using the TCP, HTTP, SSL, or other protocol by changing appropriate configuration parameters at 
runtime. Thus, the application developer may not have to write any transport specific code. A client 
library and the broker 202 may handle the transport-specific details. 

Applicant's claim 5 recites: 

5. The computer network architecture of claim 4, wherein the first tunneling protocol 
opens the hyper text transfer protocol connection ^the second tunneling protocol is not 
successful in opening the transmission control protocol connection. 
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(Emphases added.) 
Firstly , 

Claim 5 is dependent on claim 4 which is dependent on claim 3 which is dependent 
on claim 1 , and as discussed above in the claim 1 discussion, Bavadekar fails to disclose 
multiplexing a plurality of messages for transmission through the first tunneling layer, 
therefore Bavadekar cannot anticipate Applicant's claim 5. Further, Bavadekar cannot 
anticipate the further limitation of Applicant's claims 3, 4, and 5. Applicant respectfully 
requests allowance of claim 5. 

Secondly , 

Nowhere in the cited section does Bavadekar disclose or discuss the condition where 
another protocol is tried jfa first one is not successful (i.e. first protocol is attempted if a 
second protocol is not successful). Since Bavadekar does not disclose this limitation of 
Applicant's claim 5, Bavadekar cannot anticipate Applicant's claim. 

Summary - claim 5 

For the above reasons, Bavadekar cannot anticipate Applicant's claim 5. Applicant 
respectfully requests allowance of claim 5. 
// 
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Fourth Office - Claim 6 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 1 0 states: 

10. As per claim 6, Bavadekar- Puj are disclose the messages include 
binary format [Pujare, digital signals, 0155] . 

Applicant notes that at this point, it is unclear as to whether the Office is referring to 
the Bavadekar reference mentioned or to Pujare, therefore Applicant will discuss both. 

The cited references state: 

(Pujare) [0155] E) Network Spoofing for Client-server Applications 

(Bavadekar) [0155] Various embodiments may further include receiving, sending or storing 
instructions and/or data implemented in accordance with the foregoing description upon a carrier 
medium. Generally speaking, a carrier medium may include storage media or memory media such as 
magnetic or optical media, e.g., disk or CD-ROM, volatile or non-volatile media such as RAM (e.g. 
SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. as well as transmission media or signals 
such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as 
network and/or a wireless link. 

Applicant's claim 6 recites: 

6. The computer network of claim 1 , wherein the messages include binary format 
messages. 
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Firstly , 

With respect to Bavadekar: 

Claim 6 is dependent on claim 1 , and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 6. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 6. Applicant 
respectfully requests allowance of claim 6. 

Secondly , 

With respect to Pujare: 

Pujare at the cited section only discloses "Network Spoofing for Client-server 
Applications" and does not disclose multiplexing a plurality of messages for transmission 
through the first tunneling layer which Applicant has claimed in claim 1 . Therefore Pujare 
cannot anticipate Applicant's claim 1 upon which claim 6 is dependent and cannot anticipate 
Applicant's claim 6. Further, Pujare fails to disclose or suggest the further limitations of 
claim 6. Applicant respectfully requests allowance of claim 6. 

Summary - claim 6 

For the above reasons, neither Bavadekar nor Pujare anticipate Applicant's claim 6. 
Applicant respectfully requests allowance of claim 6. 
// 
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Fifth Answer - Claim 6 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 
The Office at 8. states: 

8. As per claim 6, Bavadekar discloses the messages include binary 
format [Bavadekar, digital signals, 0155] . 

The cited reference states: 

[0155] Various embodiments may further include receiving, sending or storing instructions 
and/or data implemented in accordance with the foregoing description upon a carrier medium. 
Generally speaking, a carrier medium may include storage media or memory media such as magnetic 
or optical media, e.g., disk or CD-ROM, volatile or non-volatile media such as RAM (e.g. SDRAM, 
DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. as well as transmission media or signals such as 
electrical, electromagnetic, or digital signals, conveyed via a communication medium such as 
network and/or a wireless link. 

Applicant's claim 6 recites: 

6. The computer network of claim 1 , wherein the messages include binary format 
messages. 
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Claim 6 is dependent on claim 1 , and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 6. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 6. Applicant 
respectfully requests allowance of claim 6. 

Summary - claim 6 

For the above reasons, Bavadekar does not anticipate Applicant's claim 6. Applicant 
respectfully requests allowance of claim 6. 
// 
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Fourth Office - Claim 7 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 1 1 states: 

11. As per claim 7, Bavadekar- Puj are disclose the plurality of 
messages includes a plurality of operational messages and a plurality 
of administrative messages [Bavadekar, administrative control, 0038]. 

The cited reference states: 

[0038] In an enterprise that uses the Internet, a proxy server is a server that acts as an intermediary 
between a workstation user and the Internet so that the enterprise can ensure security, administrative 
control , and caching service. A proxy server may be associated with or part of a gateway server that 
separates the enterprise network from the outside network and a firewall server that protects the 
enterprise network from outside intrusion. 

(Emphasis added.) 

Applicant's claim 7 recites: 

7. The computer network architecture of claim 1 , wherein the plurality of messages 
includes a plurality of operational messages and a plurality of administrative messages. 

Firstly , 

Claim 7 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 7. Further, 
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Bavadekar cannot anticipate the further limitation of Applicant's claim 7. Applicant 
respectfully requests allowance of claim 7. 

Secondly , 

Applicant submits that the Office is incorrectly equating Bavadekar's "administrative 
control" with Applicant's "administrative messages". Control is not the same as messages. 

Thirdly , 

Applicant notes that the Office mentions Pujare in paragraph 11 . but cites no 
reference or argument. Applicant submits that Pujare does not anticipate the limitations of 
claim 1 or claim 7. 



Summary - claim 7 

For the above reasons, Bavadekar does not anticipate Applicant's claim 7. Applicant 
respectfully requests allowance of claim 7, and claims 8-9 which are dependent on claim 7. 

// 
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Fifth Answer - Claim 7 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 

The Office at 9. states: 

9. As per claim 7, Bavadekar discloses [sic] the plurality of 
messages includes a plurality of operational messages and a plurality 
of administrative messages [Bavadekar, administrative control, 0038]. 

The cited reference states: 

[0038] In an enterprise that uses the Internet, a proxy server is a server that acts as an intermediary 
between a workstation user and the Internet so that the enterprise can ensure security, administrative 
control , and caching service. A proxy server may be associated with or part of a gateway server that 
separates the enterprise network from the outside network and a firewall server that protects the 
enterprise network from outside intrusion. 

(Emphasis added.) 

Applicant's claim 7 recites: 

7. The computer network architecture of claim 1 , wherein the plurality of messages 
includes a plurality of operational messages and a plurality of administrative messages. 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 333 of 1275 



Application No. 09/912636 



Appl. No. 09/912,636 
Appellant's Reply Brief 

Firstly , 

Claim 7 is dependent on claim 1, and as discussed above in the claim 1 discussion, 
Bavadekar fails to disclose multiplexing a plurality of messages for transmission through the 
first tunneling layer, therefore Bavadekar cannot anticipate Applicant's claim 7. Further, 
Bavadekar cannot anticipate the further limitation of Applicant's claim 7. Applicant 
respectfully requests allowance of claim 7. 

Secondly , 

Applicant submits that the Office is incorrectly equating Bavadekar's "administrative 
control" with Applicant's "administrative messages". Control is not the same as messages. 

Thirdly , 

Assuming arguendo that Bavadekar's "administrative control" is similar to Applicant's 
administrative messages, Bavadekar still fails to disclose Applicant's operational messages. 
Applicant has claimed both - "a plurality of operational messages and a plurality of 
administrative messages." (Emphases added.) 

Summary - claim 7 

For the above reasons, Bavadekar does not anticipate Applicant's claim 7. Applicant 
respectfully requests allowance of claim 7, and claims 8-9 which are dependent on claim 7. 

// 
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Fourth Office - Claim 8 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 12 states: 

12. As per claim 8, Bavadekar- Puj are disclose the operational 
messages include operational data [Pujare, parameter, 0148] . 

Applicant again notes that at this point, it is unclear as to whether the Office is 
referring to the Bavadekar reference mentioned or to Pujare, therefore Applicant will discuss 
both. 

The cited references state: 

(Pujare) [0148] i) Client License Manager 303~This is the same component explained 

above. 

(Bavadekar) [0148] Either client 200 or server 202 may set connection options. This may be 
used to control the runtime parameters associated with a connection. For example, this may be used 
to control how often packets are pulled from a Web server. As another example, this may be used to 
configure how long a client may remain inactive before the connection is dropped. The connection 
option values are part of the connection state information, and hence, in one embodiment, an HTTP 
packet including the following information may be used to update the connection options: 

Applicant's claim 8 recites: 
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8. The computer network architecture of claim 7, wherein the operational messages 
include operational data. 

Firstly , 

With regard to Bavadekar: 

Claim 8 is dependent on claim 7 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 8. Further, Bavadekar cannot anticipate the further limitations of 
Applicant's claims 7 and 8. Applicant respectfully requests allowance of claim 7. 

Secondly , 

With respect to Pujare: 

Pujare at the cited section only discloses "Client License Manager 303--This is the same 
component explained above." and does not disclose multiplexing a plurality of messages for 
transmission through the first tunneling layer which Applicant has claimed in claim 1 . 
Therefore Pujare cannot anticipate Applicant's claim 1 upon which claim 8 is dependent and 
cannot anticipate Applicant's claim 8. Further, Pujare fails to disclose or suggest the further 
limitations of claims 7 and 8. Applicant respectfully requests allowance of claim 8. 
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Summary - claim 8 

For the above reasons, neither Bavadekar nor Pujare anticipate Applicant's claim 8. 
Applicant respectfully requests allowance of claim 8. 
// 
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Fifth Answer - Claim 8 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 
The Office at 1 0. states: 

10. As per claim 8, Bavadekar discloses the operational messages 
include operational data [Bavadekar, parameter, 0148] . 

The cited reference states: 

[0148] Either client 200 or server 202 may set connection options. This may be used to 
control the runtime parameters associated with a connection. For example, this may be used to control 
how often packets are pulled from a Web server. As another example, this may be used to configure 
how long a client may remain inactive before the connection is dropped. The connection option 
values are part of the connection state information, and hence, in one embodiment, an HTTP packet 
including the following information may be used to update the connection options: 

Applicant's claim 8 recites: 

8. The computer network architecture of claim 7, wherein the operational messages 
include operational data. 
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Firstly , 

Claim 8 is dependent on claim 7 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 8. Further, Bavadekar cannot anticipate the further limitations of 
Applicant's claims 7 and 8. Applicant respectfully requests allowance of claim 7. 

Secondly , 

Claim 8 is dependent on claim 7 and as discussed above in the claim 7 discussion 

the Office is incorrectly equating Bavadekar's "administrative control" with Applicant's 
"administrative messages". Control is not the same as messages. 

Thirdly , 

Claim 8 is dependent on claim 7 and as discussed above in the claim 7 discussion 
assuming arguendo that Bavadekar's "administrative control" is similar to Applicant's 
administrative messages, Bavadekar still fails to disclose Applicant's operational messages. 
Applicant has claimed both - "a plurality of operational messages and a plurality of 
administrative messages." (Emphases added.) 
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Summary - claim 8 

For the above reasons, Bavadekar does not anticipate Applicant's claim 8. Applicant 
respectfully requests allowance of claim 8. 
// 
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Fourth Office - Claim 9 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at 1 3 states: 

13. As per claim 9, Bavadekar- Puj are disclose the administrative 
messages can be selected from the group consisting of debug messages, 
firmware update messages and parameter configuration messages [Puj are, 
update options, parameter , 0148] . 

Applicant again notes that at this point, it is unclear as to whether the Office is 
referring to the Bavadekar reference mentioned or to Pujare, therefore Applicant will discuss 
both. 



The cited references state: 

(Pujare) [0148] i) Client License Manager 303~This is the same component explained 

above. 

(Bavadekar) [0148] Either client 200 or server 202 may set connection options. This may be 
used to control the runtime parameters associated with a connection. For example, this may be used 
to control how often packets are pulled from a Web server. As another example, this may be used to 
configure how long a client may remain inactive before the connection is dropped. The connection 
option values are part of the connection state information, and hence, in one embodiment, an HTTP 
packet including the following information may be used to update the connection options: 
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Applicant's claim 9 recites: 

9. The computer network architecture of claim 7, wherein the administrative messages 
can be selected from the group consisting of debug messages, firmware update messages 
and parameter configuration messages. 

Firstly , 

With regard to Bavadekar: 

Claim 9 is dependent on claim 7 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 9. Further, Bavadekar cannot anticipate the further limitations of 
Applicant's claims 7 and 9. Applicant respectfully requests allowance of claim 9. 



Secondly , 

With respect to Pujare: 

Pujare at the cited section only discloses "Client License Manager 303--This is the same 
component explained above." and does not disclose multiplexing a plurality of messages for 
transmission through the first tunneling layer which Applicant has claimed in claim 1 . 
Therefore Pujare cannot anticipate Applicant's claim 1 upon which claim 9 is dependent and 
cannot anticipate Applicant's claim 9. Further, Pujare fails to disclose or suggest the further 
limitations of claims 7 and 9. Applicant respectfully requests allowance of claim 9. 
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Summary - claim 9 

For the above reasons, neither Bavadekar nor Pujare anticipate Applicant's claim 9. 
Applicant respectfully requests allowance of claim 9. 

// 
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Fifth Answer - Claim 9 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 5 states: 
The Office at 11 . states: 

11. As per claim 9, Bavadekar discloses the administrative messages 
can be selected from the group consisting of debug messages, firmware 
update messages and parameter configuration messages [Bavadekar, 
administrative control, 0038] . 

The cited reference states: 

[0038] In an enterprise that uses the Internet, a proxy server is a server that acts as an intermediary 
between a workstation user and the Internet so that the enterprise can ensure security, administrative 
control , and caching service. A proxy server may be associated with or part of a gateway server that 
separates the enterprise network from the outside network and a firewall server that protects the 
enterprise network from outside intrusion. 

(Emphasis added.) 

Applicant's claim 9 recites: 
9. The computer network architecture of claim 7, wherein the administrative messages 
can be selected from the group consisting of debug messages, firmware update messages 
and parameter configuration messages. 
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Firstly , 

With regard to Bavadekar: 

Claim 9 is dependent on claim 7 which is dependent on claim 1 , and as discussed 
above in the claim 1 discussion, Bavadekar fails to disclose multiplexing a plurality of 
messages for transmission through the first tunneling layer, therefore Bavadekar cannot 
anticipate Applicant's claim 9. Further, Bavadekar cannot anticipate the further limitations of 
Applicant's claims 7 and 9. Applicant respectfully requests allowance of claim 9. 

Secondly , 

Claim 9 is dependent on claim 7 and as discussed above in the claim 7 discussion 

the Office is incorrectly equating Bavadekar's "administrative control" with Applicant's 
"administrative messages". Control is not the same as messages. 

Thirdly , 

Claim 9 is dependent on claim 7 and as discussed above in the claim 7 discussion 
assuming arguendo that Bavadekar's "administrative control" is similar to Applicant's 
administrative messages, Bavadekar still fails to disclose Applicant's operational messages. 
Applicant has claimed both - "a plurality of operational messages and a plurality of 
administrative messages." (Emphases added.) 
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Fourthly , 

Bavadekar fails to disclose debug messages, firmware update messages, or parameter 
configuration messages. Therefore Bavadekar cannot anticipate Applicant's claim 9. 

Summary - claim 9 

For the above reasons Bavadekar does not anticipate Applicant's claim 9. Applicant 
respectfully requests allowance of claim 9. 

// 
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Fourth Office - Claims 12-18 and 21-27 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

Applicant notes that while claims 12-18 and 21-27 stand rejected under 35 U.S.C. § 
102(e) as being anticipated by Bavadekar that the Office has failed to particularly address 
each of the claims. 

Applicant submits that for substantially the same reasons as detailed above in the 
claims 1-9 discussions that claims 12-18 and 21-27 are not anticipated by the cited art. 
Applicant respectfully requests allowance of claims 12-18 and 21-27. 

// 
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Fifth Answer - Claims 10-27 Rejection under 35 U.S.C. ^ 102(e) - Bavadekar 

The Office at (9) Page 6 states: 
The Office at 12. states: 

12. Claims 10-27 contain the identical limitations set forth of 
apparatus claims 1-9. Therefore, claims 10-27 are rejected for the 
similar rationale set forth in claims 1-9. 

Applicant submits that for substantially the same reasons as detailed above in the 
claims 1-9 discussions that claims 10-27 are not anticipated by the cited art. Applicant 
respectfully requests allowance of claims 10-27. 

// 
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CONCLUSION 

Applicant submits that the rejection of dependent claims not specifically addressed, 
are addressed by Applicant's arguments to the independent claims on which they depend. 

Applicant respectfully submits that the appealed claims in this application are 
patentable, and requests that the Board of Patent Appeals and Interferences direct 
allowance of all claims. 

Respectfully submitted, 
Heimlich Law 

05/30/2008 /Alan Heimlich/ 

Date Alan Heimlich / Reg 48808 

Attorney for Applicant(s) 

Customer No. 40418 

5952 Dial Way 
San Jose, CA 95129 

Tel: 408 253-3860 

EmI: alanheimlich(S)heimlichlaw.com 
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VIII. CLAIMS APPENDIX 

The claims involved in this appeal (all pending claims) are as follows: 

CLAIMS 

What is claimed is: 

1 . (original) A computer network architecture comprising: 

a first layer including a transmission control protocol connection; 

a second layer including a hyper text transfer protocol connection built upon the first 

layer; 

a first tunneling layer including a first tunneling protocol built upon the second layer to 
tunnel a message through the hyper text transfer protocol connection; and 

a multiplexing layer to multiplex a plurality of messages for transmission through the 
first tunneling layer. 

2. (original) The computer network architecture of claim 1 , wherein the first tunneling 
protocol opens the hyper text transfer protocol connection between a server and a client. 

3. (original) The computer network architecture of claim 1 , further comprising: 

a second tunneling layer including a second tunneling protocol built upon the first 
layer to tunnel a message through the transmission control protocol connection. 
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4. (original) The computer network architecture of claim 3, wherein the second tunneling 
protocol is used to open the transmission control protocol connection between the server 
and the client. 

5. (original) The computer network architecture of claim 4, wherein the first tunneling 
protocol opens the hyper text transfer protocol connection if the second tunneling protocol is 
not successful in opening the transmission control protocol connection. 

6. (original) The computer network of claim 1 , wherein the messages include binary 
format messages. 

7. (original) The computer network architecture of claim 1 , wherein the plurality of 
messages includes a plurality of operational messages and a plurality of administrative 
messages. 

8. (original) The computer network architecture of claim 7, wherein the operational 
messages include operational data. 

9. (original) The computer network architecture of claim 7, wherein the administrative 
messages can be selected from the group consisting of debug messages, firmware update 
messages and parameter configuration messages. 

1 0. (original) A method for a computer network architecture comprising: 
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building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the hyper text transfer protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the hyper text transfer 
protocol connection by using a multiplexing layer. 

1 1 . (original) The method of claim 10, wherein opening the hyper text transfer protocol 
connection between a server and a client by using the first tunneling layer. 

12. (original) The method of claim 10, further comprising: 

tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
transmission control protocol connection. 

13. (original) The method of claim 12, wherein opening the transmission control protocol 
connection between a server and a client by using the second tunneling protocol. 

14. (original) The method of claim 13, wherein opening the hyper text transfer protocol 
connection by using the first tunneling protocol if the transmission control protocol 
connection is not successfully opened by using the second tunneling protocol. 

15. (original) The method of claim 10, wherein the messages include binary format 
messages. 
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16. (original) The method of claim 10, wherein the plurality of messages include a 
plurality of operational messages and a plurality of administrative messages. 

17. (original) The method of claim 16, wherein the operational messages include 
operational data. 

18. (original) The method of claim 16, wherein the administrative messages can be 
selected from the group consisting of debug messages, firmware update messages and 
parameter configuration messages. 

19. (original) A computer readable medium having instructions which, when executed by 
a processing system, cause the system to perform a method comprising: 

building a hyper text transfer protocol connection upon a transmission control 
protocol connection; 

tunneling a message through the Hyper Text Transfer Protocol connection by using a 
first tunneling protocol layer including a first tunneling protocol; and 

multiplexing a plurality of messages for transmission through the Hyper Text Transfer 
Protocol connection by using a multiplexing layer. 

20. (original) The medium of claim 19, wherein opening the Hyper Text Transfer Protocol 
connection between a server and a client by using the first tunneling layer. 



21 . (original) The medium of claim 19, further comprising: 
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tunneling a message through the transmission control protocol connection by using a 
second tunneling protocol layer including a second tunneling protocol built upon the 
Transmission Control Protocol Connection. 

22. (original) The medium of claim 21 , wherein opening the Transmission Control 
Protocol connection between a server and a client by using the second tunneling protocol. 

23. (original) The medium of claim 22, wherein opening the Hyper Text Transfer Protocol 
connection by using the first tunneling protocol if the Transmission Control Protocol 
connection is not successfully opened by using the second tunneling protocol. 

24. (original) The medium of claim 19, wherein the messages include binary format 
messages. 

25. (original) The medium of claim 19, wherein the plurality of messages include a 
plurality of operational messages and a plurality of administrative messages. 

26. (original) The medium of claim 25, wherein the operational messages include 
operational data. 

27. (original) The medium of claim 25, wherein the administrative messages can be 
selected from the group consisting of debug messages, firmware update messages and 
parameter configuration messages. 
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IX. EVIDENCE APPENDIX 

Grouping of any Evidence for Claim purposes is for the convenience of 
reduced duplication and is NOT to be interpreted as the Grouping of Claims for 
Arguments under 37 C.F.R. § 41.37. 

(A) Evidence for Claims 1-27 - Relied Upon 

The following item (1) listed below is hereby entered as evidence relied upon by the 
Examiner as to grounds of rejection for claims 1-27, to be reviewed on appeal. Also listed 
for each item is where said evidence was entered into the record by the Examiner. 

(1) Copy of US Patent Application Number 20030009571 ("Bavadekar"). This evidence was 
entered into the record by the Examiner on page 3 paragraph 3. of the Office Action mailed 
03/23/2006. 

Copies of all References follows. 

// 
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us 20030009571A1 

) United States 

) Patent Application Publication (lo) Pub. No.: US 2003/0009571 Al 

Bavadekar (43) Pub. Date: Jan. 9, 2003 



(54) SYSTEM AND METHOD FOR PROVIDING 
TUNNEL CONNECTIONS BETWEEN 
ENTITIES IN A MESSAGING SYSTEM 

(76) Inventor: Shailesh S. Bavadekar, Sunnyvale, CA 
(US) 

Correspondence Address: 
Robert C. Kowert 
Conley, Rose, & Tayon, P.C. 
P.O. Box 398 

Austin, TX 78767-1400 (US) 

(21) Appl. No.: 09/894,318 

(22) Filed: Jun. 28, 2001 

Publication Classification 
(51) Int. CI.' G06F 15/16 



(52) U.S. CI 709/230; 709/203 

(57) ABSTRACT 

A system and method for providing HTTP tunnel connec- 
tions between entities such as clients and servers in a 
messaging system is described. An HTTP tunnel connection 
layer is described that may be used to provide reliable, full 
duplex virtual connections between entities (e.g. clients and 
brokers) in a distributed application environment using a 
messaging system. Also described is a novel HTTP tunnel- 
ing protocol that may be used by the HTTP tunnel connec- 
tion layer. The HTTP tunnel connection layer may be used 
by clients to access messaging servers through proxy servers 
and firewalls, thus expanding the scope of from where 
clients can access brokers. Using this layer, brokers as well 
as clients may initiate messaging system messages. This 
layer may also provide guaranteed data delivery with correct 
sequencing even in case of a failure on the network. This 
layer may also provide end-to-end flow control. 
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broker via the tunnel connection 
606 



The broker acknowledges receipt of the 
one or more packets via the tunnel 
connection 
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Transmit the one or more packets to the 
broker via the tunnel connection 
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Packets pass through a proxy server 
(optional) 
620 



Packets pass through one or more 
firewalls (optional) 
622 



A Web server receives the one or more 
packets 
624 



The Web server forwards the one or 
more packets to the broker 
626 



The broker receives the packets 
628 



Figure 6B 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 365 of 1275 



Application No. 09/912636 



Patent Application Publication Jan. 9, 2003 Sheet 10 of 14 US 2003/0009571 Al 



The broker acknowledges receipt of the one 
or more packets via the tunnel connection 



The broker sends one or more ACK 
packets to the Web server 



The Web server stores the 
acknowledgement packets in a buffer 
542 



The client sends a pull request packet 
to the Web server 
644 



The Web server transmits the one or 
more ACK packets to the client 
646 



Packets pass through one or more 
firewalls (optional) 

m 



Packets pass through a proxy server 
(optional) 
650 
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Generate one or more transport 
protocol packets encapsulating the one 
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one or more packets via the tunnel 
connection 
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The Web server stores the packets in a 
buffer 
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The client sends a pull request packet 
to the Web server 
724 

1 

The Web server transmits the one or 
more packets to the client 
726 



Packets pass through one or more 
firev/alls (optional) 
728 



Packets pass through a proxy server 
(optional) 
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The client receives the packets 
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The client acknowledges receipt of ttie one 
or more packets via the tunnel connection 



The client sends one or more ACK 
packets to the broker 
740 



The ACK packets pass through a proxy 
server (optional) 
Z42 



The ACK packets pass through one or 
more firewalls (optional) 
744 



The Web sen/er receives the one or 
more ACK packets 
746 



The Web server forwards the one or 
more ACK packets to the broker 
748 



The broker receives the ACK packets 
750 
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SYSTEM AND METHOD FOR PROVIDING 
TUNNEL CONNECTIONS BETWEEN ENTITIES IN 
A MESSAGING SYSTEM 

BACKGROUND OF THE INVENTION 
[0001] 1. Field of the Invention 

[0002] Tliis invention relates to computers and networks 
of computers, and more particularly to a system and method 
for providing transport protocol tunnel connections between 
entities or nodes such as clients and servers in a messaging 

[0003] 2. Description of the Related Art 
[0004] Messaging is playing an increasingly important 
role in computing. Its advantages are a natural result of 
several factors: the trend toward peer-to-peer computing, 
greater platform heterogeneity, and greater modularity, 
coupled with the trend away from synchronous communi- 
cation between processes. The common building block of a 
messaging ser\'ice is the message. Messages are specially 
formatted data describing events, requests, and replies that 
are created by and delivered to computer programs. Mes- 
sages contain formatted data with specific meanings. Mes- 
saging is the exchange of messages to a messaging server, 
which acts as a message exchange program for client 
programs. A messaging server is a middleware program that 
handles messages that are sent by client programs for use by 
other programs. Typically, client programs access the func- 
tionality of the messaging system using a messaging appli- 
cation program interface (application program interface). A 
messaging server can usually queue and prioritize messages 
as needed, and thus saves each of the client programs from 
having to perform these services. Rather than communicate 
directly with each other, the components in an application 
based aroimd a message service send messages to a message 
server. The message server, in turn, delivers the messages to 
the specified recipients 

[0005] Tltere are two major messaging system models: the 
point-to-point model and the publish and subscribe model. 
Messaging allows programs to share common message- 
handhng code, to isolate resources and interdependencies, 
and to easily handle an increase in message volume. Mes- 
saging also makes it easier for programs to communicate 
across different programming environments (languages, 
compilers, and operating systems) since the only thing that 
each environment needs to understand is the common mes- 
saging format and protocol. The messages involved 
exchange crucial data between computers — rather than 
between users — and contain information such as event noti- 
fication and service requests. IBM's MOSeries and iPlanet 
Message Queue are examples of products that provide 
messaging interfaces and services. 

[0006] FIG. 1 illustrates a typical messaging-based appli- 
cation. This appUcation is a modification of the traditional 
client/server architecture. The major difference is the pres- 
ence of a messaging server lOOA between cKent 102 and 
server 104 layers. Thus, rather than communicating directly, 
cKents 102 and servers 104 communicate via the messaging 
server lOOA. The addition of the messaging server lOOA 
adds another layer to the application, but it greatly simplifies 
the design of both the clients 102 and the servers 104 (they 
are no longer responsible for handling communications 



issues), and it also enhances scalability. Note that servers in 
a messaging system may also be referred to as "brokers". 

[0007] FIG. 2 illustrates another messaging-based appli- 
cation based on point-to-point architecture, litis type of 
appHcation almost demands a centralized messaging server 
lOOB. Without one, each component 106 would be respon- 
sible for creating and maintaining connections with the other 
components 106. A possible alternative approach would be 
to architect the system around a communication bus, but this 
would still leave each component 106 in charge of message 
delivery issues. 

[0008] Java Message Service (JMS) 
[0009] Java Message Service (JMS) is an application 
program interface (API) from Sun Microsystems that sup- 
ports messaging between computers in a network. JMS 
provides a common interface to standard messaging proto- 
cols and also to special messaging services in support of 
Java programs. Sun advocates the use of the JMS for anyone 
developing Java applications, which can be run from any 
major operating system platform. Using the JMS interface, 
a programmer can invoke the messaging services of IBM's 
MQSeries, Progress Software's SonicMQ, and other mes- 
saging product vendors. 
[0010] The JMS API may: 

[0011] Provide a single, unified message API 

[0012] Provide an API suitable for the creation of 
messages that match the format used by existing, 
non-JMS applications 

[0013] Support the development of heterogeneous 
applications that span operating systems, platforms, 
architectures, and computer languages 

[0014] Support messages that contain seriaKzed Java 

[0015] Support messages that contain extensible 
Markup Language (XML) pages 

[0016] Allow messages to be prioritized 

[0017] Deliver messages either synchronously or 
asynchronously 

[0018] Guarantee messages are delivered once and 
only once 

[0019] Support message delivery notification 
[0020] Support message time-to-live 
[0021] Support transactions 

[0022] The JMS API is divided into two nearly identical 
pieces. One implements a point-to-point model of messag- 
ing, and the other implements a publish and subscribe model 
of messaging. Each of these models is called a domain. The 
APIs are almost identical between the domains. The sepa- 
ration of the API into two domains relieves vendors that 
support only one messaging model from providing facilities 
their product doesn't natively support. 
[0023] Enterprise Messaging Systems 

[0024] Enterprise messaging systems may be developed 
using a messaging service such as JMvS. An enterprise 
messaging system may be used to integrate distributed. 
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loosely coupled applications/systems in a way that provides 
for dynamic topologies of cooperating systems/services. 
Enterprise messaging systems typically need to address 
common messaging related problems such as: 

[0025] Guaranteed message delivery (e.g. persis- 
tence, durable interests, "at least once" and "once 
and only once" message delivery guarantees, trans- 
actions etc). Messages from one component to 
another must not be lost due to network or system 
failure. This means the system must be able to 
guarantee that a message is successfully delivered. 

[0026] Asynchronous delivery. For large numbers of 
components to be able to exchange messages simul- 
taneously, and support high density throughputs, the 
sending of a message cannot depend upon the readi- 
ness of the consumer to immediately receive it. If a 
consumer is busy or offline, the system must allow 
for a message to be sent and subsequently received 
when the consumer is ready. This is known as 
asynchronous message delivery, popularly known as 
store-and-forward messaging. 

[0027] Various message deKvery models (e.g. publish 
and subscribe or point-to-point). 

[0028] Transport independence. 

[0029] Leveraging an enterprise messaging system in 
developing business solutions allows developers to focus on 
their application/business logic rather than on implementing 
the underlying messaging layer. 

[0030] iPlanet E-Commerce Solutions' iMQ (iplanet Mes- 
sage Queue), formerly offered by Sun Microsystems as JMQ 
(Java Message Queue) is an example of an enterprise 
messaging system, and was developed to be JMS-complianl. 
iMQ may use a "hub and spoke" architecture. Clients use an 
iMQ client library to exchange messages with an iMQ 
message server (also referred to as a "broker"). 
[0031] In an enterprise messaging system, clients 
exchange messages with a messaging server using a mes- 
sage exchange protocol. The messaging server then may 
route the messages based upon properties of the messages. 
Typically, the message exchange protocol requires a direct, 
fully bi-directional reUable transport connection between the 
cKent and the messaging server, such as a TCP (Transport 
Control Protocol) or SSL (Secure Sockets Layer) connec- 
tion, which can be used only if the client and the messaging 
server both reside on the "intranet" (i.e. on the same side of 
a firewall). 

[0032] Hypertext Transfer Protocol 
[0033] The Hypertext Transfer Protocol (HTTP) is a set of 
rules for exchanging files (text, graphic images, sound, 
video, and other multimedia files) on the World Wide Web. 
HTTP may also be used on an intranet. Relative to the 
TCP/IP suite of protocols (which are the basis for informa- 
tion exchange on the Internet), HTTP is an apphcation 
protocol that is implemented over TCP/IP HTTP was 
designed as a stateless request-response mechanism. 
[0034] A Web ser\'er is a program that, using the client/ 
server model and HTTP, serves the files that form Web pages 
to Web users (whose computers contain HTTP clients that 
forward their requests). Every computer on the Internet that 



contains a Web site must have a Web ser\'er. A Web server 
machine may include, in addition to the Hypertext Markup 
Language (HTML) and other files it can serve, an HTTP 
daemon, a program that is designed to wait for HTTP 
requests and handle them when they arrive. A Web browser 
is an example of an HTTP client that sends requests to server 
machines. When a browser user enters file requests by either 
"opening" a Web file by typing in a URL (Uniform Resource 
Locator) or chcking on a hypertext link, the browser builds 
an HTTP request and sends it to the Internet Protocol (IP) 
address mdicated by the URL. The H TTP daemon in the 
destination server machine receives the request and, after 
any necessary processing, the requested file is returned. 

[0035] Tunneling 

[0036] Tunneling may be defined as the encapsulation of 
a pro tocolAwithin protocols, such thatAtreatsB as though 
it were a data hnk layer. Tunneling may be used to get data 
between administrative domains that use a protocol that is 
not supported by the Internet connecting those domains. A 
"tunnel" is a particular path that a given message or file 
might travel through the Internet. 
[0037] Proxy Servers and Firewalls. 
[0038] In an enterprise that uses the Internet, a proxy 
server is a server that acts as an intermediary between a 
workstation user and the Internet so that the enterprise can 
ensure security, administrative control, and caching service. 
A proxy server may be associated with or part of a gateway 
server that separates the enterprise network from the outside 
network and a firewall server that protects the enterprise 
network from outside intrusion. 

[0039] A firewall is a set of related programs, usually 
located at a network gateway server, that protects the 
resources of a private network from users from other net- 
works. An enterprise with an intranet that allows its workers 
access to the wider Internet installs a firewall to prevent 
outsiders from accessing its own private data resources and 
for controlling what outside resources its own users have 
access to. 

SUMMARY OF THE INVENTION 

[0040] A system and method for providing transport pro- 
tocol tunnel connections between entities such as clients and 
servers in a messaging system is described. A transport 
protocol tunnel connection layer is described that may be 
used to provide rehable, full duplex virtual connections 
between entities (e.g. cUents and servers) in a distributed 
apphcation environment using a messaging system. This 
layer may be used by clients to access messaging servers 
(referred to as brokers) through proxy servers and firewalls, 
thus expanding the scope of from where clients can access 
brokers. This layer allows for information flow in both 
directions between the client and the server Using this layer, 
brokers as well as clients may initiate messages in the 
distributed application environment. This layer may also 
provide guaranteed data delivery with correct sequencing 
even in case of a failure on the network. This layer may also 
provide end-to-end flow control. 

[0041] The transport protocol tunnel connection layer may 
provide a connection-oriented, bi-directional byte stream 
service between nodes in a messaging system. Application 
data, including messages, may be carried as transport pro- 
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tocol packet payloads. The transport protocol tunnel con- 
nection layer allows messaging system cUents to access 
messaging system brokers using the transport protocol 
instead of using direct TCP connections. This enables the 
cKcnts to access the brokers through firewalls. Also, with the 
help of a transport protocol proxy, the chents may access the 
messaging service even when there is no direct IP connec- 
tivity with the broker. 

[0042] Using embodiments of the transport protocol tun- 
nel connection layer, a transport protocol tunnel connection 
between the client and the broker in the messaging system 
may be established. The client may then generate one or 
more messaging system messages. In one embodiment, the 
generated messages may then be stored in a client-side 
transmit buffer. One or more transport protocol packets 
encapsulating the one or more messages may then be 
generated on the client. In one embodiment, a client-side 
tunnel connection driver may generate the packets and 
include the messages as payloads of the packets. The one or 
more transport protocol packets may then be transmitted to 
the broker via the tunnel connection. In one embodiment, the 
cKent-side tunnel connection driver may handle the trans- 
mission of the packets. 

[0043] A Web server may then receive the one or more 
transport protocol packets. The Web server may then for- 
ward the received transport protocol packets to the broker. In 
one embodiment, the packets may be forwarded to the 
broker via a TCP connection serving as one segment of the 
transport protocol tunnel connection between the Web server 
and the broker. In one embodiment, a transport protocol 
tunnel servlet on the Web server node may serve as an 
interface between the Web server and the TCP connection. 
[0044] The broker may receive the transport protocol 
packets from the Web server. In one embodiment, a broker- 
side transport protocol tunnel driver may receive the pack- 
ets. In one embodiment, the broker may extract the mes- 
saging system messages from the transport protocol packets 
and store the messages in a broker-side receive buffer. In 
another embodiment, the entire transport protocol packet 
may be stored in the broker-side receive buffer. 

[0045] The broker may acknowledge receipt of the packets 
by sending one or more acknowledgement (ACK) packets to 
the client via the tunnel connection. The broker may gen- 
erate and send one or more acknowledgement (ACK) pack- 
ets to the Web server. In one embodiment, the broker may 
store ACK packets in a broker-side transmit buffer. In one 
embodiment, the ACK packets may be sent to the Web 
server over the TCP connection. In one embodiment, the 
broker-side transport protocol tunnel driver may handle the 
transmission of the ACK packets to the Web server. 
[0046] The Web server may then receive the ACK packets. 
In one embodiment, a transport protocol tunnel servlet may 
receive the packets for the Web server. The Web server may 
store the acknowledgement packets in a transport protocol 
packet buffer. At some point, the client may send a transport 
protocol puU request packet to the Web server. In one 
embodiment, the client may periodically send pull requests 
to the Web server. In one embodiment, a separate thread on 
the client may handle periodically sending pull requests. The 
Web server may transmit to the client the one or more 
transport protocol ACK packets stored in the transport 
protocol packet buffer associated with the client in response 



to receiving the pull request packet. The client may then 
receive the one or more ACK packets. The ACK packets 
may serve to acknowledge the receipt of the transmitted data 
so that the sender may free its transmit buffers. 

[0047] Using embodiments of the transport protocol tun- 
nel connection layer, messaging system messages may be 
generated on a broker and sent to a client. In one embodi- 
ment, the generated messages may be stored in a broker-side 
transmit buffer. One or more transport protocol packets 
encapsulating the one or more messages may then be 
generated on the broker. In one embodiment, a broker-side 
transport protocol timnel connection driver may generate the 
transport protocol packets and include the messages as 
payloads of the packets. The one or more transport protocol 
packets may then be transmitted to the client via the trans- 
port protocol tunnel connection. In one embodiment, the 
broker-side transport protocol tunnel connection driver may 
handle the transmission of the packets. In one embodiment, 
the transport protocol packets may be sent to a Web server. 
In one embodiment, the transport protocol packets may be 
sent to the Web server over a TCP connection. 
[0048] The Web server may receive the transport protocol 
packets and store the received packets in a transport protocol 
packet buffer. In one embodiment, a transport protocol 
tunnel servlet may receive the packets for the Web server. At 
some point, the client may send a transport protocol pull 
request packet to the Web server. The Web server may 
transmit to the client one or more transport protocol packets 
stored in the transport protocol packet buffer associated with 
the client in response to receiving the pull request packet. 
[0049] The chent may then receive the one or more 
transport protocol packets. In one embodiment, the client 
may store the received transport protocol packets in a 
client-side receive buffer. After receiving the transport pro- 
tocol packets, the client may acknowledge receipt of the 
packets by sending one or more acknowledgement (ACK) 
packets to the broker via the transport protocol tunnel 
connection. The Web server may receive the ACK packets 
and forward the received ACK packets to the broker. In one 
embodiment, the ACK packets may be transmitted to the 
broker via a TCP connection between the Web server and the 
broker that serves as one segment of the HTTP tunnel 
connection. The broker may receive the ACK packets from 
the Web server. In one embodiment, the received ACK 
packets may be stored in a broker-side receive buffer. 

[0050] In one embodiment, one Web server and one tunnel 
servlet may be used by two or more clients to communicate 
to a broker via tunnel connections. In this embodiment, the 
HTTP tunnel servlet may multiplex transport protocol pack- 
ets from the two or more clients onto the TCP connection. 
In one embodiment, the tunnel servlet may extract the 
messaging system message information from received trans- 
port protocol packets and send only the message information 
to the broker over the I'CP connection. In one embodiment, 
there may be one broker-side receive buffer for each tunnel 
connection. In another embodiment, a single receive buffer 
may be used for two or more tunnel connections. 

[0051] Transport protocol packets may optionally pass 
through a proxy server and one or more firewalls. For 
example, transport protocol packet flow from a client to a 
broker may pass through a proxy server, through a firewall 
onto the Internet, through another firewall to a Web server, 
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and from the Web server over a TCP connection to the 
broker. Packets flowing in the opposite direction (from the 
broker to the client) take the reverse path. 
[0052] In one embodiment, transport protocol packets 
transmitted on the tunnel connection may include message 
sequence information configured for use by the receiver in 
processing received messages in the correct sequence. In one 
embodiment, flow control may be applied to the sending of 
messages from a sender to a receiver. In one embodiment, 
the receiver may inform the sender of available space in a 
receive buffer to store incoming messages. In one embodi- 
ment, upon establishment of a tunnel connection, each side 
(both chents and brokers can be senders and/or receivers) 
may inform the other of its receive buffer size. In one 
embodiment, ACK packets sent to a sender by a receiver 
may each include the currently available space in the receive 
buffer. Thus, the sender can keep track of the current receive 
capacity of the receiver. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0053] FIG. 1 illustrates a prior art messaging-based 
application based upon client/server architecture; 
[0054] FIG. 2 illustrates a prior art messaging-based 
application based on point-to-point architecture; 
[0055] FIG. 3A illustrates a client-server messaging sys- 
tem implementing a transport protocol tunnel connection 
layer according to one embodiment; 

[0056] FIG. 3B illustrates a chent-server messaging sys- 
tem implementing a transport protocol tunnel connection 
layer with multiple clients accessing a broker through a Web 
server according to one embodiment; 
[0057] FIG. 4 illustrates the architecture of a chent-server 
messaging system implementing a transport protocol tunnel 
connection layer according to one embodiment; 

[0058] FIG. 5A illustrates the routing of transport proto- 
col packets between clients and a broker on transport 
protocol tunnel connections according to one embodiment; 

[0059] FIG. 5B illustrates the process of sending a mes- 
sage from a client to a broker via a transport protocol tunnel 
connection according to one embodiment; 

[0060] FIG. 5C illustrates the process of sending a mes- 
sage from a broker to a client via a transport protocol tunnel 
connection according to one embodiment; 
[0061] FIGS. 6A IS a flowchart of a method for sending 
messages from a messaging system client to a messaging 
system broker over a transport protocol tunnel connection 
layer according to one embodiment; FIG. 6B is a flowchart 
of a method for transmitting one or more packets from a 
chent to a broker via a transport protocol tunnel connection 
according to one embodiment; 

[0062] FIG. 6C is a flowchart of a method for a broker to 
acknowledge to a client the receipt of transport protocol 
packets via the transport protocol tunnel connection accord- 
ing to one embodiment; 

[0063] FIG. 7A is a flowchart of a method for sending 
messages from a messaging system client to a messaging 
system broker over a transport protocol tunnel connection 
layer according to one embodiment; 



[0064] FIG. 7B is a flowchart of a method for transmitting 
one or more packets from a broker to a client via a transport 
protocol tunnel connection according to one embodiment; 
[0065] FIG. 7C is a flowchart of a method for a client to 
acknowledge to a broker the receipt of transport protocol 
packets via a transport protocol tunnel connection according 
to one embodiment; and 

[0066] FIG. 8 illustrates an exemplary transport protocol 
packet format that may be used in the transport protocol 
tunnel connection layer according to one embodiment. 
[0067] While the invention is described herein by way of 
example for several embodiments and illustrative drawings, 
those skilled in the art will recognize that the invention is not 
hmited to the embodiments or drawings described. It should 
be understood, that the drawings and detailed description 
thereto are not intended to limit the invention to the par- 
ticular form disclosed, but on the contrary, the intention is to 
cover all modifications, equivalents and alternatives faUing 
within the spirit and scope of the present invention as 
defined by the appended claims. The headings used herein 
are for organizational purposes only and are not meant to be 
used to hmit the scope of the description or the claims. As 
used throughout this application, the word "may" is used in 
a permissive sense (i.e., meaning having the potential to), 
rather than the mandatory sense (i.e., meaning must). Simi- 
larly, the words "include", "including", and "includes" mean 
including, but not limited to. 

DETAILED DESCRIPTION OF EMBODIMENTS 
OF THE INVENTION 

[0068] A system and method for providing transport pro- 
tocol tunnel connections between entities such as clients and 
servers in a messaging system is described. A transport 
protocol tunnel connection layer is described that may be 
used to provide reliable, full duplex virtual connections 
between entities (e.g. chents and servers) in a distributed 
apphcation environment using a messaging system. This 
layer may be used by clients to access messaging servers 
(referred to as brokers) through proxy servers and firewalls, 
thus expanding the scope of from where clients can access 
brokers. Using this layer, brokers as well as clients may 
initiate messages in the distributed application environment. 
This layer may also provide guaranteed data delivery with 
correct sequencing even in case of a faflure on the network. 
This layer may also provide end-to-end flow control. The 
transport protocol tunnel connection layer may be used to 
simulate virtual connections that have a similar contract with 
the upper layers (e.g. clients and brokers) as a TCP connec- 
tion. Thus, applications can be developed in terms of mes- 
sages without concern for the particular underlying connec- 
tion protocol. Decisions about the best communications 
protocol between clients and brokers may be postponed until 
deployment time when the particular network requirements 
of an instaUation are known. 

[0069] The transport protocol tunnel connection layer may 
use a novel tunneling protocol to overcome hmitations of the 
underlying transport protocol in the messaging environment. 
A transport protocol may be designed as a stateless request- 
response mechanism, and thus may not fit the enterprise 
messaging system protocol model very well. For example, 
enterprise messaging system applications may expect asyn- 
chronous message delivery whereas a transport protocol 
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may use a synchronous request response model. As another 
example, each transport protocol request-response exchange 
may carry a fmite amount of data and is usually short lived. 
Thus, an enterprise messaging system message may be 
delivered using multiple transport protocol requests. How- 
ever there may be no correlation between transport protocol 
requests generated by the same client. The Web servers and 
transport protocol intermediaries (e.g. proxy servers) thus 
cannot guarantee that the transport protocol requests will be 
processed in the same sequence as they were sent. As yet 
another example, TCP protocol uses a flow control mecha- 
nism to limit the network resource usage. If an enterprise 
messaging system message sender application generates 
messages very rapidly, and if each message is sent to the 
server using a separate transport protocol request or multiple 
transport protocol requests, resources on the transport pro- 
tocol servers and intermediaries may be exhausted. As still 
yet another example, an enterprise messaging system client 
application may maintain a connection and a steady message 
exchange rate over very long periods of time (many days or 
even months). If the transport protocol is used, a failure on 
a common transport protocol proxy server may disrupt the 
communication between the client application and the enter- 
prise messaging system broker. 

[0070] The transport protocol tunnel connection layer may 
provide a connection-oriented, bi-directional byte stream 
service between nodes in a messaging system. Transport 
protocol messages may be carried as transport protocol 
packet payloads. The transport protocol tunnel connection 
layer may allow messaging system clients to access mes- 
saging system brokers using the transport protocol instead of 
using direct TCP connections. This enables the clients to 
access the brokers through firewalls. Also, with the help of 
a transport protocol proxy, the clients may access the mes- 
saging service even when there is no direct IP connectivity 
with the broker. 

[0071] Using the transport protocol tunnel connection 
layer, if a cUent is separated from a broker by a firewall, 
messaging may be run on top of transport protocol connec- 
tions, which are normally aUowed through firewalls. On the 
chent side, a transport protocol transport driver may encap- 
sulate messages into transport protocol packets, and also 
may ensure that these packets are sent to the Web server in 
the correct sequence. The chent may use a transport protocol 
proxy server to communicate with the broker if necessary. In 
one embodiment, a transport protocol tunnel sendet execut- 
ing within a Web server may receive the transport protocol 
packets and forward the entire transport protocol packets 
(including the message data) to the broker. In another 
embodiment, the transport protocol tunnel servlet executing 
within the Web server may be used to puU client data 
(messages) out of the transport protocol packets before 
forwarding the data to the broker. In one embodiment, the 
tunnel servlet may multiplex message data from multiple 
chents onto one TCP connection to the broker, thus aflowing 
the use of one tunnel servlet for multiple clients. The 
transport protocol tunnel servlet may also send broker data 
(messages) to the client in response to transport protocol pull 
requests. On the broker side, a transport protocol transport 
driver may unwrap and demultiplex incoming messages 
from the transport protocol tunnel servlet. The transport 
protocol tunnel connection layer may also be used by 
brokers to initiate communications with a client. 



[0072] Though embodiments of the system and method 
are described herein as providing Hypertext Transport Pro- 
tocol (HTTP) tunnel connections between entities such as 
clients and servers in a messaging system, it is noted that 
embodiments of the system and method using other unreh- 
able/connectionless transport protocols that may not have 
buih-in TCP support such as UDP (User Datagram Proto- 
col), IrDA (Infrared Data Association), IBM's SNA (Sys- 
tems Network Architecture), Novell's IPX (Internetwork 
Packet exchange), and Bluetooth are contemplated. These 
embodiments may be used to provide tunnel connections 
between entities in messaging systems using the other 
transport protocols. 

[0073] FIG. 3A illustrates a client-server messaging sys- 
tem implementing an HTTP tunnel connection layer accord- 
ing to one embodiment. Client 200 may generate messages 
using the messaging protocol 212. In one embodiment, an 
Application Programming Interface (API) to the messaging 
protocol may be used by the client application to generate 
the messages. In one embodiment, the messaging protocol is 
the Java Message Service (JMS). Other messaging protocols 
may be used. Generated messages may then be passed to the 
HTTP tunnel client driver 220. 

[0074] The HTTP tunnel client driver 220 may then send 
the messages as HTTP POST request payloads. The HTTP 
tunnel client driver 220 may also use separate HTTP 
requests to periodically pull any data sent by the other end 
of the connection. The HTTP requests may be sent through 
HTTP proxy 206, Internet 204, and firewall 210 to Web 
server 208. On Web server 208, the HTTP tunnel servlet 214 
may act as a transceiver and may multiplex the HTTP 
requests from multiple clients onto a single TCP connection 
216 with the broker 202. The HTTP tunnel broker driver 240 
may receive the HTTP requests from the Web server 210 
over TCP connection 216. 

[0075] Note that the HTTP proxy 206 and/or the firewall 
210 are optional. In other words, the HTTP tunnel connec- 
tion layer is configurable to transmit messages encapsulated 
in HTTP requests between entities over the Internet 104 both 
with and without the messages passing through proxies 
and/or firewalls. Also note that the Web server 208, HTTP 
tunnel servlet 214, and the broker 202 may be implemented 
on the same host machine or on different host machines. 
Note also that a Web server 208 and H'lT'P tunnel servlet 214 
may be used to access multiple brokers 202. 

[0076] In one embodiment, the packet delivery service 
provided by the HTTP tunnel drivers may occasionally lose 
packets. Hence the HTTP tunnel connection layer may use 
positive acknowledgements of received packets, and may 
retransmit any lost packets. When a receiver receives a 
packet including a message, the receiver responds to the 
packet by sending an acknowledgement packet to the sender. 

[0077] In one embodiment, the HTTP tunnel connection 
layer may use a sliding window protocol to implement 
packet sequencing and flow control on top of HTTP. In a 
distributed apphcation environment using a messaging ser- 
vice, quite often entities may need to send a stream of 
packets, without errors, and with guaranteed order of deliv- 
ery (i.e. that the packets are received in the order they are 
sent). HTTP does not guarantee packets to be received by a 
receiver (e.g. broker) in the same order the packets were sent 
by a transmitter (e.g. client). Also, HTTP does not provide 
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a method to control the rate at which packets are sent to a 
receiver, thus running the risk of exhausting network 
resources on the receiver and losing packets. Using a shding 
window protocol provides the ability to control the rate at 
which packets arc transmitted to a receiver. The shding 
window protocol may he used to guarantee that no more than 
a fixed number of packets are transmitted to a receiver. The 
fixed number of packets may be determined by a receive 
buffer size on the receiver. For example, a receiver may be 
able to receive a maximum of 100 packets from a sender. If 
the sender initially transmits 70 packets, the receiver may 
receive the packets and process 20 of them. Tlie receiver 
may send a packet or packets to notify the sender that the 
receiver can receive 50 packets. The sender may then 
transmit 30 more packets. The receiver may receive the 30 
packets, and in the meantime may have processed 20 more 
of the original 70 packets. The receiver may then transmit a 
packet or packets to notify the sender that the receiver can 
receive 60 packets (there are stiU 10 of the original 70 
packets and the 30 new packets in the receive buffer). Thus, 
the sender never sends more packets to the receiver than the 
quantity of packets the receiver has notified the sender it can 

[0078] In one embodiment, when a connection is estab- 
lished between two entities or nodes (e.g. a server and 
client), each node may inform the other of how many 
packets it can initially receive. In a network, a node is a 
connection point, either a redistribution point or an end point 
for data transmissions. In general, a node has programmed 
or engineered capability to recognize, process and/or for- 
ward transmissions to other nodes. In one embodiment, each 
packet received by the receiver may be acknowledged with 
a packet sent to the sender. The acknowledgement packets 
may each include information indicating the current receive 
buffer size (i.e. the number of packets that the receiver can 
currently receive). Thus, the sender can determine the num- 
ber of packets that it can send to the receiver without 
overwhelming the sender. 

[0079] In one embodiment, the client 200, broker 202 and 
the messaging protocol layers 212 may function similarly 
whether the underlying transport protocol is TCP or HTTP. 
In one embodiment, the messaging protocol layers 212 on 
both the client and the broker may use the same basic design 
and threading model for TCP and HTTP support. In one 
embodiment, an enterprise messaging system using the 
HTTP tunneling protocol may allow a messaging system 
application to exchange messages using the TCP, HTTP, 
SSL, or other protocol by changing appropriate configura- 
tion parameters at runtime. Thus, the application developer 
may not have to write any transport specific code. A cUent 
library and the broker 202 may handle the transport-specific 
details. 

[0080] FIG. 3B illustrates a chent-server messaging sys- 
tem implementing the HTTP tunnel connection layer with 
mukiple clients accessing a broker through a Web server 
according to one embodiment. Both brokers 202 A and 202B 
may have registered with Web server 208 that they are ready 
to receive connections from clients. Client 200Amay estab- 
hsh an HTTP tunnel connection to broker 202 A through Web 
server 208. Chent 200B may estabhsh an HTTP tunnel 
connection to broker 202B through Web server 208. At some 
point, either client may establish an HTTP tunnel connection 
with the other broker. Thus, a client may have multiple 



HTTP tunnel connections open to different brokers, and 
muhiple clients may have HTTP tunnel connections open to 

[0081] FIG. 4 illustrates the architechire of a chent-server 
messaging system implementing the HTTP tunnel connec- 
tion layer according to one embodiment. Various compo- 
nents that are comprised in the network protocol stack for 
the HTTP tunnel connection layer are shown. These com- 
ponents lie between the appheation (chent or broker) and the 
HTTP tuimel driver (client or broker). These components 
may include an HTTP tunnel input stream.TITTP tunnel 
output stream 270, an HTTP tunnel socket 272, and an 
HTTP tunnel connection 274. In one embodiment, these 
components may be implemented as classes. In one embodi- 
ment, these components may be implemented as Java 
classes. 

[0082] The HTTP tunnel drivers may send one request or 
receive one packet at a time. The primary responsibility of 
these drivers is to make sure that single packets are sent 
and/or received. This driver may not be aware of or be 
involved directly in the ordering, flow control or acknowl- 
edgement of packets. 

[0083] The HTTP tunnel connection component 274 may 
interpret received packets. This component may be respon- 
sible for the sliding window protocol implementation. This 
component may be responsible for buffering the packets, 
may implement flow control, reordering and other aspects of 
the HTTP tunneling protocol. This component may be the 
primary component that is used to implement the end-to-end 
HTTP tunnel "virtual" connection as described herein. 
[0084] The HTTP tunnel socket 272 and input and output 
streams 270 provide an interface between the application 
(e.g. client or broker) and the HTTP tunnel connection 274. 
These components may include simple, atomic methods 
such as read, write and open connection methods that 
provide an abstract interface to the HTTP tunnel connection 
274 for the applications, and thus may hide the HTTP tunnel 
connection implementation from the applications. 
[0085] HTTP tunnel server socket 276 may be used by 
broker 202 to open a listening socket to the Web server 208 
to allow the Web server to create a listening endpoint for the 
broker 202. In doing so, broker 202 is establishing that it is 
ready to accept HTTP tunnel connections through Web 
server 208. Thus, when client 200 desires to open an HTTP 
tunnel connection to broker 202, the client may contact Web 
server 208 with a packet including information identifying 
broker 202. Web server 208 may examine the packet and 
forward the packet to broker 202, where an HTTP tunnel 
connection to client 200 may be established. Note that one 
or more HIT'P packet buflers may be allocated on Web 
server 208 for the newly established HTTP tunnel connec- 
tion. Thus, a client 200 initiates a connection, and a broker 
202 accepts the coiuiection. In one embodiment, brokers 202 
cannot initiate connections to clients. Therefore, once an 
HTTP tunnel connection between a chent 200 and a broker 
202 is open (initiated by the chent 200), the chent 200 may 
keep the connection open so that if the broker 202 has data 
to send to the client, there is a communications link estab- 
hshed for the broker to send messages to the client on. In one 
embodiment, the broker 202 never sends HTTP packets 
direcfly to the chent 200; the packets are buffered on Web 
server 208, and pulled from the Web server periodically by 
the chent 200. 
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[0086] FIGS. 5A through 5C are data flow diagrams 
illustrating the operation of a client-broker messaging sys- 
tem implementing the HTTP tunnel connection layer 
according to one embodiment. FIG. 5A illustrates the rout- 
ing of HTTP packets between clients 200 and a broker 202 
on HTTP hinnel connections 292 according to one embodi- 
ment. Each client 200 may include at least one chent-side 
transmit buffer 222 and at least one client-side receive buffer 
224. Broker 202 may include at least one broker-side receive 
buffer 244 and at least one broker-side transmit buffer 242. 
Each client 200 may establish an H'iT'P tunnel connection 
292 to broker 202, which mav pass through network 294, 
through Web server 208, and over a TCP connection 296 to 
broker 202. There may be a single TCP connection 296 
between Web server 208, or alternatively a TCP connection 
296 may be established for each HTTP tunnel connection 
292. In passing through network 294, an HTTP tunnel 
connection 292 may pass through a proxy server (not 
shown) and/or through one or more firewalls (not shown). 
[0087] Clients 200 may generate messaging system mes- 
sages, which may be buffered in a chent-side transmit buffer 
222. Buffering message data may aUow messages to be 
retransmitted if necessary, for example. Tlie clients 200 may 
generate HTTP packets that include the message data as 
payloads and transmit the HTTP message packets to broker 
202 via the HTTP tunnel connections 292 as indicated at 
280A and 280B. Web server 208 may receive the HTTP 
message packets from network 294 and forward the packets 
to broker 202 over a TCP connection 296. 
[0088] Broker 202 may buffer incoming messages in a 
broker-side receive buffer 244. Broker 202 may generate an 
acknowledgment (ACK) HTTP packet to acknowledge the 
receipt of each HTTP packet successfully received from a 
chent 200, and send the ACK packets to Web server 208 
over a TCP connection 296 as indicated at 282A and 282B. 
Web server 208 may buffer the ACK packets received from 
broker 202 in buffers 250. In one embodiment, there may be 
a buffer 250 for each HTTP tunnel connection 292; in other 
words, each connection 292 may use a separate instance of 
buffer 250. In another embodiment, one buffer 250 may be 
shared among two or more HTTP tunnel connections 292. 
[0089] Using the HTTP tunnehng protocol laver, a broker 
202 as well as clients 200 may initiate messaging system 
messages. Messages generated by broker 202 may be buff- 
ered in a broker-side transmit buffer 242. Buffering message 
data may allow messages to be retransmitted if necessary, 
for example. The broker 202 may generate HTTP packets 
that include the message data as payloads and transmit the 
HTTP packets to Web server 208 over a TCP connection 296 
as indicated at 288A and 288B. Web server 208 may buffer 
the H'IT'P message packets received from broker 202 in 
buffers 250. 

[0090] As indicated at 284A and 284B, each client 200 
may send an HTTP request packet to Web server 208 to 
indicate that the chent 200 is ready to receive HTTP packets 
buffered in a buffer 250 for the client 200. In one embodi- 
ment, each client may periodically send HTTP request 
packets to retrieve buffered H'i'l'P packets from Web server 
208. In one embodiment, a separate thread on a client 200 
may be responsible for periodically sending the HTTP 
request packets. 

[0091] After Web server 208 receives an HTTP request 
packet from a client 200 as indicated at 284, the Web server 



208 may respond by sending the requesting chent 200 one 
or more HTTP packets currentiy buffered in a buffer 250 for 
the chent 200. The HTTP packets may include ACK packets 
as sent at 282 and/or HTTP message packets as sent at 288. 
Upon receiving HTTP packets from the Web server 208, a 
client 200 may store the received packets in a chent-side 
receive buffer 224 to await processing. A client 200 may also 
generate an ACK packet and send them to broker 202 over 
the HTTP tunnel connection, as indicated at 290A and 290B, 
in response to each HTTP message packet received. 
[0092] FIG. 5B illustrates the process of sending a mes- 
sage from a client 200 to a broker 202 via an HTTP tunnel 
connection according to one embodiment. At 300, the client 
200 may generate a message 260A. At 302, the chent side 
HTTP tunnehng driver 220 may receive the message 260A 
and buffer the outgoing message data in a transmit buffer 
222, which may allow the message data to be retransmitted 
if necessary. The chent side HTTP tunnehng driver 220 
generates an HTTP POST request with the message data as 
payload as indicated at 304. This HTTP request may travel 
over the Internet. The client 200 may be configured to send 
HTTP requests via a proxy server 206 and through one or 
more firewalls 210 if necessary. 

[0093] A Web server 208 may receive the HTIP request 
with the message data, and forward the HTTP request to the 
server side HTTP tunnehng driver 240 over a TCP connec- 
tion as indicated at 306. The server side HTTP tunnehng 
driver 240 may store the received message data in a receive 
buffer 244. The packet header of the HTTP request may 
include a sequence number for use in preserving message 
order when multiple messages are transmitted. The message 
data may remain in receive buffer 244 untff the broker 202 

[0094] The server side HTTP tunneling driver may gen- 
erate an acknowledgement (ACK) HTTP packet to indicate 
successful receipt of the HTTP request packet and message 
data, i'he ACK packet may include information about how 
much space is left in the receive buffer 244. This information 
may be used as a "flow control" mechanism to slow down 
the sender (chent) ff the receiver (broker) cannot consume 
the data fast enough. The ACK packet may be sent to the 
Web server 208 over the TCP connection as indicated at 308. 
The ACK packet may be stored in packet buffer 250A on the 
Web ser\'er 208 waiting for an HTTP request from the client 
200. In one embodiment, the Web server 208 may not initiate 
communication with the client 200; it can only respond to 
incoming HTTP requests. 

[0095] The client side HTTP tunneling driver 220 then 
may send an HTTP request packet to the Web ser\'er 208 to 
pull any pending H IT'P packets as indicated at 310. In one 
embodiment, the chent side HTTP tunnehng driver 220 may 
use a separate reader thread that continuously sends requests 
to the Web server 208 to puU any pending HTTP packets. 
After the Web server 208 receives a puff request for the 
HTTP packet buffered at 308, the Web server may send the 
buffered HTTP packet(s) to client 200 in response to the pull 
request as indicated at 312. The client side HTTP tunneling 
driver 220 then may process the HTTP packet(s) including 
the ACK packet, and free the corresponding message data 
buffered in transmit buffer 222 at 302. In one embodiment, 
information from the HTTP packet(s) sent to the client 200 
may be stored in a client-side receive buffer (not shown) and 
accessed from the client-side receive buffer for processing. 
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[0096] FIG. 5C illustrates the process of sending a mes- 
sage from the broker 202 to the cUent 200 via an HTTP 
tunnel connection according to one embodiment. At 400, the 
broker 202 generates a message 260B. At 402, the broker 
side HTTP tunneling driver 240 may receive the message 
260B and buffer the outgoing message data in a transmit 
buffer 242 so that it can be retransmitted if necessary. The 
broker side HTTP tunneling driver 240 may generate an 
HTTP packet with the message data as pavload and forward 
it to Web server 208 over a TCP connection as indicated at 
404. The Web server 208 receives the HTTP packet with the 
message data, and writes the packet to buffer 250. The server 
side HTTP tunneUng driver 240 may send an HTTP request 
to the Web server 208 to pull any pending packets as 
indicated at 406. When the Web server 208 receives the pull 
request, it sends the packet buffered at 404 in response to the 
pull request as indicated at 408. The client side HTTP 
tunneling driver 220 may store the received message data in 
a receive buffer 224. The packet header of the HTTP request 
may include a sequence number to preserve message order. 
The message data may remain in receive buffer 224 until the 
cKent 200 consumes it. 

[0097] The client side HTTP tunneling driver generates an 
acknowledgement (ACK) HTTP packet to indicate success- 
ful receipt of the HTTP request and message data. The ACK 
packet may also include information about how much space 
is left in receive buffer 224. This information may be used 
as a "flow control" mechanism to slow down the sender 
(broker) if the receiver (client) cannot consume the data fast 
enough. The ACK packet may be sent to the Web server 208 
over the Internet as indicated at 410. Web server 208 may 
forward the ACK packet to the server side HTTP tunneling 
driver 240 over a TCP connection as indicated at 412. The 
server side HTTP tunnehng driver 240 then may free the 
corresponding message data packet(s) buffered in transmit 
buffer 242 at 402. In one embodiment, information from the 
ACK packet sent to the broker 202 may be stored in a 
broker-side receive buffer (not shown) and accessed from 
the broker-side receive buffer for processing. 

[0098] FIGS. 6A-6C are flowcharts illustrating a method 
of sending messages from a messaging system client to a 
messaging system broker over an HTTP tunnel connection 
layer according to one embodiment. In FIG. 6A, a transport 
protocol tunnel connection between a client and a broker in 
a messaging system may be estabhshed as indicated at 600. 
As indicated at 602, one or more messaging system mes- 
sages may be generated on the client. In one embodiment, 
the generated messages may then be stored in a cUent-side 
transmit buffer. One or more transport protocol packets 
encapsulating the one or more messages may be generated 
on the client as indicated at 604. In one embodiment, a 
client-side HTTP tunnel connection driver may generate the 
HTTP packets and include the messages as payloads of the 
packets. As indicated at 606, the one or more HTTP packets 
may then be transmitted to the broker via the HTTP tunnel 
connection. In one embodiment, the client-side HTTP tunnel 
connection driver may handle the transmission of the pack- 

[0099] In one embodiment, each HTTP packet transmitted 
on the HTTP tunnel connection may include message 
sequence information configured for use by the receiver in 
processing received messages in the correct sequence. This 
is useful since HTTP and some other transport protocols do 



not guarantee delivery of messages in order. In one embodi- 
ment, flow control may be applied to the sending of mes- 
sages from a sender to a receiver. In flow control, before 
sending new messages, the sender may determine available 
resources on the receiver to receive new messages, and then 
transmit no more messages than the receiver can handle 
based upon the available resources. In one embodiment, the 
receiver may inform the sender of available space in a 
receive buffer to store incoming messages awaiting process- 
ing. In one embodiment, upon establishment of an HTTP 
tunnel connection, each side (both clients and brokers can be 
senders and/or receivers) may inform the other of its receive 

[0100] As indicated at 608, the broker may receive the 
HTTP packets and then may acknowledge receipt of the one 
or more packets by sending one or more acknowledgement 
(ACK) packets to the client via the HTTP tunnel connection. 
In one embodiment, the ACK packets may each include the 
currently available space in the broker-side receive buffer. 
Thus, the sender (client) can keep track of the current 
receive capacity of the receiver (broker). 
[0101] FIG.6Bexpandson606ofFIG.6A nl U t ts 
a method of transmitting one or more packets from a client 
to a broker via an H IT'P tunnel connection according to one 
embodiment. As indicated at 620, the transmitted HTTP 
packets may optionally pass through a proxy server. As 
indicated at 622, the transmitted HTTP packets may option- 
ally pass through one or more firewalls. A Web server may 
then receive the one or more HTTP packets as indicated at 
624. For example, the client may transmit the packets to a 
proxy server, the proxy server may transmit the packets 
through a firewall onto the Internet, and the packets may be 
received through another firewall by the Web server. 
[0102] The Web server may then forward the received 
HTTP packets to the broker as indicated at 626. In one 
embodiment, the packets may be transmitted to the broker 
via a TCP connection between the Web server and the broker 
that serves as one segment of the HTTP tunnel connection. 
In one embodiment, an HTTP tunnel ser\'let on the Web 
server node may serve as an interface between the Web 
server and the TCP connection to the broker. In one embodi- 
ment, one Web server and HTTP tunnel servlet may be used 
by two or more cflents to communicate to a broker via HTTP 
tunnel connections. In this embodiment, the HTTP tunnel 
servlet may multiplex HTTP packets from the two or more 
clients onto the TCP connection. In one embodiment, the 
HTTP tunnel servlet may extract the messaging system 
message information from received HTTP packets and send 
only the message information to the broker over the TCP 

[0103] As indicated at 628, the broker may receive the 
HTTP packets from the Web server. In one embodiment, the 
broker may receive the packets on a TCP connection to the 
Web server. In one embodiment, a broker-side HTTP tunnel 
driver may receive the packets. In one embodiment, the 
broker may extract the messaging system messages from the 
HTTP packets and store the messages in a broker-side 
receive buffer. In another embodiment, the entire HTTP 
packet may be stored in a receive buffer. In one embodiment, 
there may be one receive buffer on the broker for each HTTP 
tunnel connection. In another embodiment, a single receive 
buffer may be used for two or more HTTP tunnel connec- 
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[0104] FIG. 6C expands on 608 of FIG. 6A and illustrates 
a method of a broker acknowledging to a client the receipt 
of HTTP packets from the client via the HTTP tunnel 
connection according to one embodiment. As indicated at 
640, the broker may generate and send one or more 
acknowledgement (ACK) packets to the Web server. In one 
embodiment, the broker may store ACK packets in a broker- 
side transmit buffer. In one embodiment, the broker may 
send one ACK packet for each received HTTP packet. In 
another embodiment, the broker may send one ACK packet 
for each completely received messaging system message. In 
one embodiment, the ACK packets may be sent to the Web 
server over a TCP connection. In one embodiment, a broker- 
side H TI'P tunnel driver may handle the transmission of the 
ACK packets on the TCP connection. In one embodiment, 
an HTTP tunnel servlet may receive the packets for the Web 

[0105] As indicated at 642, the Web server may store the 
acknowledgement packets in an HTTP packet buffer. In one 
embodiment, there may be one HTTP packet buffer for each 
HTTP tunnel connection supported by the Web server. In 
another embodiment, there may be two HTTP packet buffers 
per tunnel connection, with one H T IP packet buffer for each 
message flow direction on each tunnel connection. In yet 
another embodiment, one or more HTTP packet buffers may 

[0106] As indicated at 644, at some point, the cKent may 
send an HTTP pull request packet to the Web server. In one 
embodiment, the client may periodically send HTTP pull 
requests to the Web server. In one embodiment, a separate 
thread on the client may handle periodically sending pull 
requests. The Web server may transmit to the client the one 
or more HTTP ACK packets stored in the HTTP packet 
buffer associated with the client in response to receiving the 
pull request packet as indicated at 646. As indicated at 648, 
the transmitted ACK packets may optionally pass through 
one or more firewalls. As indicated at 750, the transmitted 
ACK packets may optionally pass through a proxy server. As 
indicated at 652, the client may then receive the one or more 
ACK packets. In one embodiment, each ACK packet may 
include information on available space in the broker-side 
receive buffer to be used in flow control of HTTP packets 
from the client to the broker. The ACK packets may serve to 
acknowledge the receipt of the transmitted data so that the 
sender may free its transmit buffers. 

[0107] FIGS. 7A-7C are flowcharts fllustrating a method 
of sending messages from a messaging system client to a 
messaging system broker over an HIT'P tunnel connection 
layer according to one embodiment. In FIG. 7A, a transport 
protocol tunnel connection between a client and a broker in 
a messaging system may be estabhshed as indicated at 700. 
As indicated at 702, one or more messaging system mes- 
sages may be generated on the broker. In one embodiment, 
the generated messages may then be stored in a broker-side 
transmit buffer. One or more transport protocol packets 
encapsulating the one or more messages may be generated 
on the broker as indicated at 704. In one embodiment, a 
broker-side HTTP tunnel connection driver may generate the 
HTTP packets and include the messages as payloads of the 
packets. As indicated at 706, the one or more HTTP packets 
may then be transmitted to the client via the HTTP tunnel 



connection. In one embodiment, the broker-side HTTP tun- 
nel connection driver may handle the transmission of the 
packets. 

[0108] As indicated at 708, the chent may receive the 
HTTP packets, and then may acknowledge receipt of the one 
or more packets by sending one or more acknowledgement 
(ACK) packets to the broker via the HTTP tunnel connec- 
tion. In one embodiment, the ACK packets may each include 
the currently avaflable space in the client-side receive buffer. 
Thus, the sender (broker) can keep track of the current 
receive capacity of the receiver (client). 
[0109] FIG. 7B expands on 706 of FIG. 7A and iUustrates 
a method of transmitting one or more packets from a broker 
to a client via an HTTP tunnel connection according to one 
embodiment. As indicated at 720, the broker may generate 
and send one or more HTTP packets to the Web server. In 
one embodiment, the broker may store the HTTP packets in 
a broker-side transmit buffer. In one embodiment, the HTTP 
packets may be sent to the Web server over a TCP connec- 
tion. In one embodiment, a broker-side HTTP tunnel driver 
may handle the transmission of the HTTP packets on the 
TCP connection. 

[0110] As indicated at 722, the Web ser\'er may receive the 
HTTP packets and store the received HTTP packets in an 
HTTP packet buffer. In one embodiment, an HTTP tunnel 
servlet may receive the packets for the Web server. As 
indicated at 724, at some point, the client may send an HTTP 
pull request packet to the Web server. In one embodiment, 
the client may periodically send HTTP pull requests to the 
Web server. The Web server may transmit to the client the 
one or more HTTP packets stored in the HTTP packet buffer 
associated with the client in response to receiving the pull 
request packet as indicated at 726. As indicated at 728, the 
transmitted HTTP packets may optionally pass through one 
or more firewalls. As indicated at 730, the transmitted HTTP 
packets may optionally pass through a proxy server. As 
indicated at 732, the client may then receive the one or more 
HTTP packets. In one embodiment, the client may store the 
received HTTP packets in a client-side receive buffer. In one 
embodiment, each HTTP packet may include sequence 
information configured for use by the client in processing 
received messages in sequence. 

[0111] FIG. 7C expands on 708 of FIG. 7A and iUustrates 
a method of a cHent acknowledging to a broker the receipt 
of HTTP packets from the broker via the HTTP tunnel 
connection according to one embodiment. As indicated at 
740, the client may generate and send one or more acknowl- 
edgement (ACK) packets to the broker. As indicated at 742, 
the transmitted ACK packets may optionally pass through a 
proxy server. As indicated at 744, the transmitted ACK 
packets may optionally pass through one or more firewalls. 
A Web server may then receive the one or more ACK 
packets as indicated at 746. For example, the client may 
transmit the ACK packets to a proxy server, the proxy server 
may transmit the ACK packets through a firewall onto the 
Internet, and the ACK packets may be received through 
another firewall by the Web server. 

[0112] The Web sen'er may then forward the received 
ACK packets to the broker as indicated at 748. In one 
embodiment, the ACK packets may be transmitted to the 
broker via a TCP connection between the Web server and the 
broker that serves as one segment of the HTTP tunnel 
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connection. In one embodiment, an HTTP tunnel servlet on 
the Web server node may serve as an interface between the 
Web server and the TCP connection to the broker. 

[0113] As indicated at 750, the broker may receive the 
ACK packets from the Web server. In one embodiment, the 
broker may receive the packets on a TCP connection to the 
Web server. In one embodiment, a broker-side HTTP tunnel 
driver may receive the ACK packets. In one embodiment, 
the received ACK packets may be stored in a broker-side 
receive buffer. In one embodiment, each ACK packet may 
include information on available space in the client-side 
receive buffer to be used in flow control of HTTP packets 
from the broker to the client. The methods as described in 
FIGS. 6A-6C and FIGS. 7A-7C may be implemented in 
software, hardware, or a combination thereof. The order of 
method may be changed, and various steps may be added, 
reordered, combined, omitted, modified, etc. 

[0114] FIG. 8 illustrates an exemplary HTTP tunneling 
protocol packet format according to one embodiment. The 
HTTP tunnel drivers at cither end of a connection may 
encode all their data packets using this packet format. Each 
messaging system message may be carried separately as a 
HTTP request or response payload. A messaging system 
message may be sent as the payload of a single packet or, 
alternatively, the message may be broken into parts and sent 
as the payload of two or more packets. 

[0115] The packet format may include several fields. Ver- 
sion 500 may indicate a version number of the packet that 
may be used to indicate different releases of the HTTP tunnel 
connection layer software. In one embodiment, the version 
500 may be a 16-bit field. Packet type 502 may indicate the 
type of the packet. This field may be used to indicate to the 
H'TI'P tunnel driver at the other end what to do with the 
contents of this packet. In one embodiment, the packet type 
field may be 16 bits. Size 504 may indicate the size of the 
entire packet including the header. In one embodiment, this 
may be a 32-bit field. Connection ID 506 may be a unique 
integer that may be used as connection identifier. This value 
may be assigned at the time of connection establishment. 
This field may be used by the server to distineuish between 
connections to multiple clients. In one embodiment, this 
may be a 32-bit field. Packet sequence number 508 may be 
used to ensure sequential delivery of data bytes and flow 
control. In one embodiment, each packet may be assigned a 
unique incremental sequence number by the sender. In one 
embodiment, this may be a 32-bit field. One embodiment 
may include a receiver window size 510 that may be used for 
flow control and may indicate the capacity of the receive 
side buffer. In one embodiment, this may be a 16-bit field. 
One embodiment may guarantee that the packets are either 
delivered correctly, or in case of an error, are not delivered 
at aU. Some embodiments may not use checksum 512, and 
thus this field may be reserved. 

[0116] One embodiment of the HTTP tunnel connection 
layer may use a connection establishment protocol that may 
be used to initiahze the foUowing connection state compo- 



[0117] The H'llP tunnel servlet 214 aUocates a 
unique connection ID for the new connection. It also 
may allocate one or more birffers 250 for packet 
streams in both directions. 



[0118] Tlie HTTP tunnel drivers on both server and 
chent side aUocate and initiafize the transmit buffers 
and receive bufl'ers for packet streams in both direc- 

[0119] The following are examples of HTTP tunnehng 
protocol packets that may be used in the connection estab- 
lishment protocol and are not intended to be hmiting. Note 
that one skilled in the art \vill recognize that other packet 
formats may be used within the scope of the invention. 
[0120] A cKent 200 may initiate a connection to a server 
202 by sending the following information in an HTTP 
packet to the HTTP tunnel servlet 214: 

[0121] URL parameters="?ServerName= 
<ServerIdString>&Type=connect" Packet Type= 
connection initialization packet (e.g. CONNJNIT- 
_PACKET (1)). 

[0122] Connection ID =0 

[0123] The servlet 214 may aUocate a unique connection 
ID for this connection and send it to the client 200 and the 
server 202 in HTTP packets including the following infor- 

[0124] Packet Typ6=connection initiaKzation packet (e.g. 
CONN_INIT_PACKET (1)). 

[0125] ConnectionID=<connid> 

[0126] This information may be sent to the client 200 as a 
response payload for the HTTP request that carried the 
client's connection initialization packet. 
[0127] The server 202 may acknowledge the connection 
initialization packet to the client 200 in an ACK packet that 
may include the foUowing information: 

[0128] Pull URL paramet6rs= 

[0129] "?ServerName=<S6rv6rIdString>&Type= 
pu U&ConnId =<connid >" 

[0130] Packet Type= 

[0131] connection initiaKzation acknowledgement 
(e.g. CONN_INIT_ACK (2)). 

[0132] After completion, both client 200 and server 202 
are aware of the newly established connection and normal 
data exchange can begin. 

[0133] Once the connection is established, both sides may 
start sending data and connection management packets. The 
following are examples of HTTP tunnehng protocol packets 
that may be used as data and connection management 
packets and are not intended to be limiting. Note that one 
skilled in the art wiU recognize that other packet formats 
may be used \vithin the scope of the invention. 
[0134] From the chent 200 to the HTTP tunnel servlet 214 
to the server 202: 

[0135] URL parameters="7ServerName= 
<S6rverIdString>&Typ6=push" 

[0136] From the serN'er 202 to the HTTP tunnel S6r\'let 214 
to the client 200: 

[0137] Pull URL parameters= 

[0138] "?ServerName=<ServerIdString>&Type= 
pull&ConnId=<connid>" 
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[0139] Each outgoing data packet (e.g. Packet Type= 
DATA_PACKET) may be assigned an incremental sequence 
number by ttie sender. The receiver may check the packet 
sequence number with its receive window. Any duplicate 
packets may be discarded. 

[0140] After consuming a packet, the receiver may 
acknowledge the highest contiguous sequence number by 
sending the ACK packet as follows: 

[0141] Packet Type=acknowledgement (e.g. ACK) 

[0142] Connection ID=<com]id> 

[0143] Sequence=<sequ6nce number of the data 
packet being acknowledged> 

[0144] Receive Window Size=<remaining receive 
window capacity> 

[0145] When an acknowledgement is received, the sender 
may update the round trip time for the connection. In one 
embodiment, a simple Knear function of the computed round 
trip time may be used as the packet retransmission interval. 
[0146] In one embodiment, when an acknowledgement 
packet reports a "Receive Window Size" of zero, the sender 
may stop sending further packets. The sender may send 
periodic repeat transmissions of the next packet to force the 
receiver to send a window update as soon as it is ready to 
receive more data. When the receiver indicates that it is 
ready to receive more data, the sender may resume sending 
packets. 

[0147] In one embodiment, the HTTP Tunneling protocol 
may support the following runtime connection option. The 
client pull period is the duration (e.g. in seconds) of the idle 
period between consecutive pull requests sent by the client. 
If this value is positive, whenever the HTTP tunnel driver on 
the client side receives an empty response to its Pull request, 
the driver may sleep for the specified period before issuing 
another pull request. Tliis may help conserve the servlet 
214's resources and hence improve connection scalability. 
[0148] Either client 200 or server 202 may set connection 
options. This may be used to control the runtime parameters 
associated with a connection. For example, this may be used 
to control how often packets are pulled from a Web server. 
As another example, this may be used to configure how long 
a client may remain inactive before the connection is 
dropped. Tire connection option values are part of the 
connection state information, and hence, in one embodi- 
ment, an HTTP packet including the following information 
may be used to update the connection options: 
[0149] Packet Type=connection option packet (e.g. CON- 
NOPTIONPACKET) 




[0150] In one embodiment, either end (client or server) 
may initiate connection shutdown by sending a connection 
close packet (e.g. Packet Type CONN_CLOSE_PACKET). 
Until both parties complete the connection shutdown, this 
packet may otherwise be treated like a normal data packet. 
This may help to ensure that all the data packets that are in 



the pipeline ahead of the connection close packet are pro- 
cessed before the connection resources are destroyed. The 
remote end may consume all the data and acknowledge the 
connection close packet, at which point the connection is 
terminated and all the resources may be freed. 

[0151] In one embodiment, a connection abort packet may 
be generated by the servlet when it realizes that either the 
server 202 or the cKent 200 has terminated ungracefully. The 
server termination may result in an lOException on the TCP 
connection between the servlet 214 and the server 202, and 
hence may be detected. In one embodiment, detecting client 
200 termination may be handled as follows. If the servlet 
214 does not receive a "pull" request from cKent 200 for a 
certain period of time, the servlet 214 may assume that the 
client 200 is not responding and thus may be down. The 
ungraceful connection shutdown may be achieved by send- 
ing a single packet with Packet Type connection abort packet 
(e.g. CONN_ABORT_PACKET) to the server 202 and 
possibly to the client 200 as well. 

[0152] The following describes the initialization of the 
link between server 200 and HTTP tunneling servlet 214 
according to one embodiment. The HTTP tunnehng servlet 
214 may listen on a fixed port number for TCP connections 
from servers. After the I'CP connection is estabhshed to 
server 200, the server 200 may send the following informa- 
tion in an HTTP tunneling protocol packet to the servlet 214: 

[0153] Packet Type: link initialization packet (e.g. LIN- 
K_INIT_PACKET) 




[0154] The ServerldString may be used to establish the 
identity of the server 200. Clients may use this string to 
specify which server they want to talk to. This allows the use 
of a single servlet 214 as a gateway for multiple servers. The 
data portion of this packet may include information about 
any existing HTTP Tunnel connections. This allows HTTP 
tunnel connections to survive unexpected Web server/servlet 
engine failures or restarts. 

[0155] Various embodiments may further include receiv- 
ing, sending or storing instructions and/or data implemented 
in accordance with the foregoing description upon a carrier 
medium. Generally speaking, a carrier medium may include 
storage media or memory media such as magnetic or optical 
media, e.g., disk or CD-ROM, volatile or non-volatile media 
such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, 
SRAM, etc.), ROM, etc. as well as tiansmission media or 
signals such as electrical, electromagnetic, or digital signals, 
conveyed via a communication medium such as network 
and/or a wireless link. 

[0156] In summary, a system and method for providing 
HTTP tunnel connections between entities such as ctients 
and servers in a messaging system have been disclosed. It 
will be appreciated by those of ordinary skill having the 
benefit of this disclosure that the illustrative embodiments 
described above are capable of numerous variations without 
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departing from the scope and spirit of tlie invention. Various 
modifications and changes may be made as would be 
obvious to a person skilled in the art having the benefit of 
this disclosure. It is intended that the following claims be 
interpreted to embrace all such modifications and changes 
and, accordingly, the specifications and drawings are to be 
regarded in an illustrative rather than a restrictive sense. 

What is claimed is: 

1. A method comprising: 

establishing a transport protocol tunnel connection from a 
first node in a messaging system to a second node in the 
messaging system; 

generating a messaging system message on the first node; 

generating one or more transport protocol packets, 
wherein the one or more transport protocol packets 
each includes at least a part of the messaging system 
message; and 

transmitting the one or more transport protocol packets to 
the second node via the transport protocol tunnel con- 
wherein the transport protocol tunnel connection provides 
full-duplex transmrssron of messagrng system mes- 
sages between the first node and the second node, and 
wherein the transport protocol tunnel connection fur- 
ther provides delivery of the messagrng system mes- 
sages in the sequence in which the messaging svstem 
messages are generated. 

2. The method as recited in claun 1. further comprising 
storing the messaging system message in a transmit buffer 
on the first node after said generating the messaging svstem 
message on the first node. 

3. The method as recited in claim f , wherein the transport 
protocol tunnel connection passes through a proxy server. 

4. The method as recited in claim 3, wherein said trans- 
mitting the one or more transport protocol packets to the 
second node via the transport protocol tunnel connection 

transmitting the one or more transport protocol packets 
from the first node to the proxy server; and 

transmitting the one or more transport protocol packets 
from the proxy server to the second node. 

5. The method as recited in claim f , wherein the transport 
protocol tunnel connection passes through at least one 
tirewah. 

6. The method as recited in claim f , wherein the transport 
protocol tunnel connection is established through a network. 

7. The method as recited in claim 6, wherein the network 
is the Internet. 

8. The method as recited in claim 1, wherein the first node 
is a chent in the messaging system, and wherein the second 
node is a broker in the messaging system. 

9. The method as recited in claim f , wherein the transport 
protocol tunnel connection passes through a third node, and 
wherein, in said transmitting the one or more transport 
protocol packets to the second node, the method further 

transmitting the one or more transport protocol packets to 
the third node; and 



the third node forwarding the one or more transport 
protocol packets to the second node. 

10. The method as recited in claim 9, wherein the one or 
more transport protocol packets are forwarded to the second 
node via a Transmission Contiol Protocol (TCP) connection 
portion of the transport protocol tunnel connection between 
the third node and the second node. 

11. The method as recited in claim 9, wherein the third 
node is a Web server. 

12. The method as recited in claim 1, wherein the trans- 
port protocol tunnel connection passes through a proxy 
server and a Web server, and wherein said transmitting the 
one or more transport protocol packets to the second node 
via the transport protocol tunnel connection comprises: 

transmitting the one or more transport protocol packets 
from the first node to the proxy server; 

transmitting the one or more transport protocol packets 
from the proxy server to the Web server; and 

the Web server forwarding the one or more transport 
protocol packets to the second node. 

13. The method as recited in claim 12, wherein the 
transport protocol tunnel connection passes through at least 
one firewall between the proxy server and the Web server. 

14. The method as recited in claim 1, wherein the one or 
more transport protocol packets include messaging system 
message sequence information configured for use in pro- 
cessing two or more messaging system messages in 
sequence. 

15. The method as recited in claim 1, further comprising: 

receiving the transmitted one or more transport protocol 
packets on the second node; and 

storing the messaging system message from the one or 
more transport protocol packets in a receive buffer on 
the second node. 

16. The method as recited in claim 1, further comprising: 

receiving the transmitted one or more transport protocol 
packets on the second node; 

the second node generating an acknowledgement trans- 
port protocol packet to indicate successful receipt of the 
one or more transport protocol packets including the 
messaging system message; and 

transmitting the acknowledgement transport protocol 
packet to the first node via the transport protocol tunnel 

17. The method as recited in claim 1 6, further comprising: 

storing the messaging system message from the received 
one or more transport protocol packets in a receive 
buffer on the second node; 

wherein the acknowledgement transport protocol packet 
includes information indicating available space in the 
receive buffer, and wherein the information indicating 
available space in the receive buffer is configured for 
use in flow control of messaging system messages 
transmitted from the first node to the second node. 

18. The method as recited in claim 17, further comprising: 

receiving the transmitted acknowledgement transport pro- 
tocol packet on the first node; 
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generating one or more messaging system messages on 
the tirst node; 

storing the one or more messaging system messages in a 
transmit buffer on the tirst node; 

determining from the information indicating available 
space in the receive buffer included in the received 
acknowledgement transport protocol packet if there is 
space available to receive the one or more messaging 
system messages on the second node; 

if said determining indicates there is space available to 
store the one or more messaging system messages in 
the receive buffer of the second node: 

generating a second one or more transport protocol 
packets, wherein the second one or more transport 
protocol packets include the one or more messaging 
system messages; and 

transmitting the second one or more transport protocol 
packets to the second node via the transport protocol 
tunnel connection; and 

if said determining indicates there is not space available 
to store the second messaging system message in the 
receive buffer of the second node, inhibiting generating 
the second one or more transport protocol packets 
including the one or more messaging system messages. 

19. The method as recited in claim 18, further comprising: 

the first node receiving a transport protocol packet indi- 
cating available space in the receive buffer of the 
second node; 

determining from the information indicating available 
space in the receive buffer included in the received 
transport protocol packet that there is space available to 
receive the one or more messaging system messages on 
the second node; 

generatrng the second one or more transport protocol 
packets, wherein the second one or more transport 
protocol packets include the one or more messaging 
system messages; and 

transmitting the second one or more transport protocol 
packets to the second node via the transport protocol 

20. The method as recited in claim 16, wherein the 
transport protocol tunnel connection passes through a third 
node, and wherein, in said transmitting the acknowledge- 
ment transport protocol packet to the first node, the method 
further comprises: 

transmitting the acknowledgement transport protocol 
packet to the third node; and 

storing the acknowledgement transport protocol packet in 
a transport protocol packet buffer on the third node. 

21. The method as recited in claim 20, wherein, in said 
transmitting the acknowledgement transport protocol packet 
to the first node, the method further comprises: 

the first node transmitting a transport protocol request 
packet to the third node; and 

the third node transmitting the acknowledgement trans- 
port protocol packet stored in the transport protocol 



packet buffer to the first node via the transport protocol 
tunnel connection in response to the transport protocol 
request packet. 

22. The method as recited in claim 21, wherein the 
acknowledgement transport protocol packet is transmitted to 
the third node via a Transmission Control Protocol (TCP) 
connection portion of the transport protocol tunnel connec- 

23. The method as recited in claim 16, wherein the 
transport protocol tunnel connection passes through a third 
node, and wherein, in said transmitting the acknowledge- 
ment transport protocol packet to the first node, the method 
further comprises: 

transmitting the acknowledgement transport protocol 
packet to the third node; and 

the third node forwarding the acknowledgement transport 
protocol packet to the first node. 

24. The method as recited in claim 23, wherein the 
acknowledgement transport protocol packet are forwarded 
to the first node via a Transmission Control Protocol (TCP) 
connection portion of the transport protocol tunnel connec- 

25. The method as recited in claim 1, wherein the first 
node is a server in the messaging system, and wherein the 
second node is a client in the messaging system. 

26. The method as recited in claim 1, wherein the trans- 
port protocol tunnel connection passes through a third node, 
and wherein, in said transmitting the one or more transport 
protocol packets to the second node via the transport pro- 
tocol tunnel connection, the method further comprises: 

transmitting the one or more transport protocol packets to 
the third node; and 

storing the one or more transport protocol packets in a 
transport protocol packet buffer on the third node. 

27. The method as recited in claim 26, wherein, in said 
transmitting the one or more transport protocol packets to 
the second node via the transport protocol tunnel connec- 
tion, the method further comprises: 

the second node sending one or more transport protocol 
request packets to the third node; and 

the third node transmitting the one or more transport 
protocol packets stored in the transport protocol packet 
buffer to the second node via the transport protocol 
tunnel connection in response to the one or more 
transport protocol request packets. 

28. The method as recited in claim 26, wherein the third 
node is a Web server. 

29. The method as recited in claim 1, wherein the trans- 
port protocol is Hypertext Transport Protocol (HTTP). 

30. The method as recited in claim 1, wherein the trans- 
port protocol is one of UDP (User Datagram Protocol), IrDA 
(Infrared Data Association), SNA (Systems Network Archi- 
tecture), IPX (Internetwork Packet eXchange), and Blue- 
tooth. 

31. A method comprising: 

establishing a Hypertext Transport Protocol (HTTP) tun- 
nel connection from a first node in a messaging system 
to a second node in the messaging system; 

generating a messaging system message on the first node; 
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generating one or more HTTP packets, wherein the one or 
more HTTP packets each includes at least a part of the 
messaging system message; and 

transmitting the one or more HTTP packets to the second 
node via the HTTP tunnel connection; 

wherein the HTTP tunnel connection provides full-duplex 
transmission of messaging system messages between 
the first node and the second node, and wherein the 
HTTP tunnel connection further provides delivery of 
the messaging system messages in the sequence in 
which the messaging system messages are generated. 

32. The method as recited in claim 31. wherein the first 
node is a chent in the messaging system, wherein the HTTP 
tunnel connection passes through a proxy server, and 
wherein said transmitting the one or more HTTP packets to 
the second node via the HTTP tunnel connection comprises: 

transmitting the one or more HTTP packets from the 
client to the proxy server; and 

transmitting the one or more HTTP packets from the 
proxy server to the second node. 

33. The method as recited in claim 31, wherem the HTTP 
tunnel connection is established through the Internet, and 
wherein the HTTP tunnel connection passes through at least 
one firewall. 

34. The method as recited in claim 31. wherein the first 
node is a client in the messaging system, and wherein the 
second node is a broker in the messaging system. 

35. The method as recited in claim 31, wherein the HTTP 
tunnel connection passes to through a Web server, wherein 
the second node is a broker in the messaging system, and 
wherein, in said transmitting the one or more HTTP packets 
to the second node, the method further comprises: 

transmitting the one or more HTTP packets to the Web 

the Web server forwarding the one or more HTTP packets 
to the broker via a Transmission Control Protocol 
(TCP) connection portion of the HTTP tunnel connec- 
tion between the Web server and the broker. 

36. The method as recited in claim 31, wherein the first 
node is a client in the messaging system, wherein the second 
node is a broker in the messaging system, wherein the H IT'P 
tunnel connection passes through a proxy server and a Web 
server, and wherein said transmitting the one or more HTTP 
packets to the broker via the HTTP tunnel connection 
comprises: 

transmitting the one or more HTTP packets from the 
client to the proxy server; 

transmitting the one or more HTTP packets from the 
proxy server to the Web server; and 

the Web server forwarding the one or more HTTP packets 
to the broker; 

wherein the HIT'P tunnel connection passes through at 
least one firewall between the proxy server and the Web 

37. The method as recited in claim 31, wherein the one or 
more HTTP packets include messaging system message 
sequence information configured for use in processing two 
or more messaging system messages in sequence. 



38. The method as recited in claim 31, further comprising; 

receiving the transmitted one or more HTTP packets on 
the second node; 

stormg the messaging system message from the one or 
more HTTP packets in a receive buffer on the second 

the second node generating an acknowledgement HTTP 
packet to indicate successful receipt of the one or more 
HTTP packets including the messaging system mes- 
sage; and 

transmitting the acknowledgement HTTP packet to the 
first node via the HTTP tunnel connection. 

39. The method as recited in claim 38, wherein the 
acknowledgement HTTP packet includes information indi- 
cating available space in the receive buller, the method 
turther comprising: 

receiving the transmitted acknowledgement HTTP packet 
on the first node; 

generating one or more messaging system messages on 
the first node; 

storing the one or more messaging system messages in a 
transmit butter on the first node; 

determining from the information indicating available 
space in the receive buffer included in the received 
acknowledgement HTTP packet that there is not space 
available to receive the one or more messaging system 
messages on the second node; 

the first node receiving an HTTP packet from the second 
node indicating available space in the receive buffer of 
the second node; 

determining from the information indicating available 
space in the receive buffer included in the received 
HTTP packet that there is space available to receive the 
one or more messaging system messages on the second 

generating a second one or more HTTP packets, wherein 
the second one or more HTTP packets include the one 
or more messaging system messages; and 

transmitting the second one or more HTTP packets to the 
second node via the HTTP tunnel connection. 

40. The method as recited in claim 38, wherein the first 
node is a client in the messaging system, wherein the HTTP 
tunnel connection passes through a Web server, and wherein, 
in said transmitting the acknowledgement HTTP packet to 
the first node, the method further comprises: 

transmitting the acknowledgement HTTP packet to the 
Web server; 

storing the acknowledgement HTTP packet in an HTTP 
packet buffer on the Web server; 

the client sending an HTTP request packet to the Web 

the Web server transmitting the acknowledgement HTTP 
packet stored in the HTTP packet buffer to the client via 
the HTTP tunnel connection in response to the HTTP 
request packet. 
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41. The method as recited in claim 38, wherein the first 
node is a broker in the messaging system, wherein the HTTP 
tunnel connection passes through a Web server, and wherein, 
in said transmitting the acknowledgement HTTP packet to 
the first node, the method further comprises: 

transmitting the acknowledgement HTTP packet to the 
Web server; and 

the Web server forwarding the acknowledgement HTTP 
packet to the first node via a Transmission Control 
Protocol (TCP) connection portion of the HTTP tunnel 

42. The method as recited in claim 31, wherein the first 
node is a server in the messaging system, and wherein the 
second node is a chent in the messaging system. 

43. The method as recited in claim 31, wherein the second 
node is a client in the messaging system, wherein the HTTP 
tunnel connection passes through a Web server, and wherein, 
in said transmitting the one or more HTTP packets to the 
second node via the HTTP tunnel connection, the method 
further comprises: 

transmitting the one or more HTTP packets to the Web 



storing the one or more HTTP packets in an HTTP packet 
buffer on the Web server; 

the client sending one or more HTTP request packets to 
the Web server; and 

the Web server transmitting the one or more HTTP 
packets stored in the HTTP packet buffer to the client 
via the HTTP tunnel connection in response to the one 
or more HTTP request packets. 

44. A method comprising: 

establishing a transport protocol tunnel connection from a 
first node in a messaging system to a second node in the 
messaging system; 

generating a sequence of messaging system messages on 
the first node; 

generating a plurality of transport protocol packets on the 
first node, wherein each of the transport protocol pack- 
ets includes at least a part of one of the sequence of 
messaging system messages, and wherein each of the 
transport protocol packets includes sequence informa- 
tion for the particular messaging system message; 

transmitting the plurahty of transport protocol packets to 
the second node in the messaging system via the 
transport protocol tunnel connection; 

receiving the plurality of transport protocol packets on the 
second node; and 

processing the sequence of messaging system messages 
on the second node, wherein said processing uses the 
sequence information for the plurality of messaging 
system messages in the plurahty of transport protocol 
packets. 

45. The method as recited in claim 44, wherein the 
transport protocol tunnel connection is established through 
the Internet, and wherein the transport protocol tunnel 
connection passes through at least one firewall. 



46. The method as recited in claim 44, wherein the first 
node is a client in the messaging system, wherein the second 
node is a broker in the messaging system. 

47. The method as recited in claim 44, wherein the second 
node is a broker in the messaging system, wherein the 
transport protocol tunnel connection passes through a Web 
server, and wherein said transmitting the plurality of trans- 
port protocol packets to the second node in the messaging 
system via the transport protocol tunnel connection com- 

transnutting the plurality of transport protocol packets 
from the first node to the Web server; and 

the Web server forwarding the plurality of transport 

protocol packets to the broker; 
wherein the transport protocol tunnel connection passes 

through at least one firewall between the proxy server 

and the Web ser\'er. 

48. The method as recited in claim 44, wherein the first 
node IS a broker in the messaging system, wherein the 
second node is a client in the messaging system. 

49. The method as recited in claim 44, wherein the second 
node IS a client in the messaging system, wherein the 
transport protocol tunnel connection passes through a Web 
server, and wherein, in said transmitting the plurality of 
transport protocol packets to the second node in the mes- 
saging system via the transport protocol tunnel connection 
comprises: 

transmitting the pluralitv of transport protocol packets to 
the Web ser\'er; 

storing the plurality of transport protocol packets in a 
transport protocol packet buffer on the Web server; 

the client sending one or more transport protocol request 
packets to the Web server; and 

the Web server transmitting the plurality of transport 
protocol packets stored in the transport protocol packet 
buffer to the client via the transport protocol tunnel 
connection in response to the one or more transport 
protocol request packets. 

50. The method as recited in claim 44, further comprising: 

storing the sequence of messaging system messages from 
the received transport protocol packets in a receive 
buffer on the second node; 

the second node generating an acknowledgement trans- 
port protocol packet for each of the received transport 
protocol packets to indicate successful receipt of the 
transport protocol packets including the sequence of 
messaging system messages; and 

transmitting the acknowledgement transport protocol 
packets to the first node via the transport protocol 

wherein each of the acknowledgement transport protocol 
packets includes information indicating available space 
in the receive buffer, wherein the information indicat- 
ing available space in the receive buffer is configured 
for use in flow control of messaging system messages 
transmitted from the first node to the second node. 

51. The method as recited in claim 44, wherein the 
transport protocol is Hypertext Transport Protocol (HTTP). 
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52. A method comprising: 

establisliing a transport protocol tunnel connection from a 
first node in a messaging system to a second node in ttie 
messaging system; 

the first node receiving a first transport protocol packet 
from the second node indicating available space in a 
receive buffer of the second node; 

generating one or more messaging system messages on 
the first node; 

storing the one or more messaging system messages in a 
transmit buffer on the first node; 

determining from tlie information indicating available 
space in the receive buffer included in the received 
acknowledgement HTTP packet that there is not space 
available to receive the one or more messaging system 
messages on the second node; 

the first node receiving a second transport protocol packet 
from the second node indicating available space in the 
receive buffer of the second node; 

determining from the information indicating available 
space in the receive buffer included in the received 
second transport protocol packet that there is space 
available to receive the one or more messaging system 
messages on the second node; 

generating one or more transport protocol packets, 
wherein the second one or more transport protocol 
packets include the generated one or more messaging 
system messages; and 

transmitting the one or more transport protocol packets to 
the second node via the transport protocol tunnel con- 

53. The method as recited in claim 52, wherein the 
transport protocol tunnel connection is established through 
the Internet, and wherein the transport protocol tunnel 
connection passes through at least one firewall. 

54. The method as recited in claim 52, wherein the first 
node is a client in the messaging system, wherein the second 
node is a broker in the messaging system. 

55. The method as recited in claim 52, wherein the first 
node is a broker in the messaging system, wherein the 
second node is a cKent in the messaging system. 

56. The method as recited in claim 52, further comprising: 

receiving the one or more transport protocol packets on 
the second node; 

storing the one or more messaging system messages from 
the received one or more transport protocol packets in 
the receive buffer on the second node; 

the second node generating one or more acknowledge- 
ment transport protocol packets to indicate successful 
receipt of the one or more transport protocol packets 
including the one or more of messaging system mes- 
sages; and 

transmitting the one or more acknowledgement transport 
protocol packets to the first node via the transport 
protocol tunnel connection; 



wherein each of the acknowledgement transport protocol 
packets includes information indicating available space 
in the receive buffer. 

57. The method as recited in claim 52, wherein the one or 
more transport protocol packets include messaging system 
message sequence information configured for use in pro- 
cessing two or more messaging system messages in 
sequence. 

58. The method as recited in claim 52, wherein the 
transport protocol is Hypertext Transport Protocol (HTTP). 

59. A messaging system comprising: 

a first node comprising a first memory; 

a second node comprising a second memory; 

wherein the first memory comprises first program instruc- 
tions executable within the first node to: 

establish a transport protocol tunnel connection from 
the first node to the second node through a network; 

generate a messaging system message; 

generate one or more transport protocol packets, 
wherein the one or more transport protocol packets 
each includes at least a part of the messaging system 
message; and 

transmit the one or more transport protocol packets to 
the second node via the transport protocol tunnel 

wherein the transport protocol tunnel connection provides 
full-duplex transmission of messaging system mes- 
sages between the first node and the second node, and 
wherein the transport protocol tunnel connection fur- 
ther provides delivery of the messaging system mes- 
sages in the sequence in which the messaging system 
messages are generated. 

60. Tire messaging system as recited in claim 59, wherein 
the first node further comprises a transmit buffer, wherein 
the first program instructions are further executable within 
the first node to store the messaging system message in the 
transmit buffer on the first node after said generating the 
messaging system message. 

61. The messaging system as recited in claim 59, wherein 
the transport protocol tunnel connection passes through a 
proxy server, and wherein, in said transmitting the one or 
more transport protocol packets to the second node via the 
transport protocol tunnel connection, the first program 
instructions are further executable within the first node to 
transmit the one or more transport protocol packets from the 
first node to the proxy server, wherein the proxy server is 
configured to transmit the one or more transport protocol 
packets to the second node. 

62. The messaging system as recited in claim 59, wherein 
the transport protocol tunnel connection passes through at 
least one firewall. 

63. The messaging system as recited in claim 59, wherein 
the transport protocol tunnel connection is estabhshed 
through the Internet. 

64. The messaging system as recited in claim 59, wherein 
the first node is a client in the messaging system, and 
wherein the second node is a broker in the messaging 
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65. The messaging system as recited in claim 59, wlierein 
the messaging system further comprises: 

a third node comprising a third memory; 

wherein the transport protocol tunnel connection passes 
through the third node, and wherein, in said transmit- 
ting the one or more transport protocol packets to the 
second node, the tirst program instructions are further 
executable within the first node to: 
transmit the one or more transport protocol packets to 

the third node; 
wherein the third memory comprises third program 
instructions executable within the third node to; 
receive the one or more transport protocol packets from 

the first node; and 
forward the one or more received transport protocol 

packets to the second node. 

66. The messaging system as recited in claim 65, wherein 
the one or more transport protocol packets are forwarded 
from the third node to the second node via a Transmission 
Control Protocol (TCP) connection portion of the transport 
protocol tunnel connection between the third node and the 
second node. 

67. The messaging system as recited in claim 66, wherein 
the transport protocol tunnel connection passes through at 
least one firewall between the first node and the third node. 

68. The messaging system as recited in claim 59, wherein 
the one or more transport protocol packets include messag- 
ing system message sequence information configured for use 
in processing two or more messaging system messages in 
sequence. 

69. The messaging system as recited in claim 59, wherein 
the second memory comprises second program instructions 
executable within the second node to: 

receive the transmitted one or more transport protocol 

generate an acknowledgement transport protocol packet 
to indicate successful receipt of the one or more trans- 
port protocol packets including the messaging system 
message; and 

transmit the acknowledgement transport protocol packet 
to the first node via the transport protocol tunnel 

70. The messaging system as recited in claim 69, wherein 
the second node further comprises a receive buffer, wherein 
the second program instructions are further executable 
within the second node to: 

store the messaging system message from the received 

one or more transport protocol packets in the receive 

buft'er of the second node; 
wherein the acknowledgement transport protocol packet 

includes information indicating available space in the 

receive buffer of the second node. 

71. The messaging system as recited in claim 70, wherein 
the first node further comprises a transmit buffer, wherein 
the first program instructions are further executable within 
the first node to: 

receive the transmitted acknowledgement transport pro- 
tocol packet; 



generate one or more messaging system messages; 

store the one or more messaging system messages in the 
transmit buffer on the first node; 

from the information indicating available space in the 
receive buffer included in the received acknowledge- 
ment transport protocol packet, determine if there is 
space available to receive the one or more messaging 
system messages on the second node; 

if said determining indicates there is space available to 
store the one or more messaging system messages in 
the receive buffer of the second node: 

generate a second one or more transport protocol 
packets, wherein the second one or more transport 
protocol packets include the one or more messaging 
system messages; and 

transmit the second one or more transport protocol 
packets to the second node via the transport protocol 
tunnel connection; and 

if said determining indicates there is not space available 
to store the second messaging system message in the 
receive buffer of the second node, inhibit generating the 
second one or more transport protocol packets includ- 
ing the one or more messaging system messages. 

72. The messaging system as recited in claim 7f , wherein 
the first program instructions arc further executable within 
the first node to: 

receive a transport protocol packet indicating available 
space in the receive buffer of the second node; 

from the information indicating available space in the 
receive buffer included in the received transport pro- 
tocol packet, determine that there is space available to 
receive the one or more messaging system messages on 
the second node; 

generate the second one or more transport protocol pack- 
ets, wherein the second one or more transport protocol 
packets include the one or more messaging system 

transmit the second one or more transport protocol pack- 
ets to the second node via the transport protocol tunnel 

73. The messaging system as recited in claim 69, further 
comprising: 

a third node comprising: 

a third memory; and 

a transport protocol packet buffer; 

wherein the transport protocol tunnel connection passes 
through the third node, wherein the third memory 
comprises third program instructions executable within 
the third node to: 

receive the acknowledgement transport protocol packet 
transmitted to the first node via the transport protocol 
tunnel connection from the second node; and 

store the received acknowledgement transport protocol 
packet in the transport protocol packet buffer. 
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74. The messaging system as recited in claim 73, wlierein 
the first program instructions are further executable within 
the first node to: 

transmit a transport protocol request packet to the third 
node; and 

wherein the third program instructions are further execut- 
able within the third node to: 

receive the transport protocol request packet from the 
first node; and 

transmit the acknowledgement transport protocol 
packet stored in the transport protocol packet bufler 
to the first node via the transport protocol tunnel 
connection in response to the received transport 
protocol request packet. 

75. The messaging system as recited in claim 69, further 
comprising: 

a third node comprising a third memory, wherein the 
transport protocol tunnel connection passes through the 
third node, wherein the third memory comprises third 
program instructions executable within the third node 

receive the acknowledgement transport protocol packet 
transmitted to the first node via the transport protocol 
tunnel connection from the second node; and 

forward the acknowledgement transport protocol 
packet to the first node. 

76. The messaging system as recited in claim 59, wherein 
the first node is a server in the messaging system, and 
wherein the second node is a client in the messagmg system. 

77. The messaging system as recited in claim 59, further 
comprising: 

a third node comprising: 

a third memory; and 

a transport protocol packet buffer; 
wherein the transport protocol tunnel connection passes 

through the third node, wherein the third memory 

comprises third program instnictions executable within 

the third node to: 

receive the one or more transport protocol packets 
transmitted to the second node via the transport 
protocol tunnel connection from the first node; and 

store the one or more transport protocol packets in the 
transport protocol packet buffer on the third node, 
wherein the second program instructions are further 

executable within the second node to transmit one or 

more transport protocol request packets to the third 

node; and 

wherein the third program instructions are further execut- 
able within the third node to: 

receive the one or more transmitted transport protocol 
request packets; and 

transmit the one or more transport protocol packets 
stored in the transport protocol packet buffer to the 
second node via the transport protocol tunnel con- 
nection in response to the received one or more 
transport protocol request packets. 



78. The messaging system as recited in claim 59, wherein 
the transport protocol is Hypertext Transport Protocol 

(HTTP). 

79. The messaging system as recited in claim 59, wherein 
the transport protocol is one of UDP (User Datagram Pro- 
tocol), IrDA (Infrared Data Association), SNA (Systems 
Network Architecture), IPX (Internetwork Packet 
exchange), and Bluetooth. 

80. A carrier medium comprising program instructions, 
wherein the program instructions are computer-executable 
to implement: 

establishing a transport protocol tunnel connection from a 
first node in a messaging system to a second node in the 
messaging system; 

generating a messaging system message on the first node; 

generating one or more transport protocol packets, 
wherein the one or more transport protocol packets 
each includes at least a part of the messaging system 

transmitting the one or more transport protocol packets to 
the second node via the transport protocol tunnel con- 
wherein the transport protocol tunnel connection provides 
full-duplex transmission of messaging system mes- 
sages between the first node and the second node, and 
wherein the transport protocol tunnel connection fur- 
ther provides delivery of the messaging system mes- 
sages in the sequence in which the messaging system 
messages are generated. 

81. The carrier medium as recited in claim 80, wherein the 
transport protocol tunnel connection passes through a Web 
server, wherein the second node is a broker in the messaging 
system, and wherein, in said transmitting the one or more 
transport protocol packets to the second node, the program 
instructions are further computer-executable to implement: 

transmitting the one or more transport protocol packets to 
the Web ser\'er; and 

the Web server forwarding the one or more transport 
protocol packets to the broker via a Transmission 
Control Protocol (TCP) connection portion of the trans- 
port protocol tunnel connection between the Web 
server and the broker. 

82. The carrier medium as recited in claim 80, wherein the 
first node is a client in the messaging system, wherein the 
second node is a broker in the messaging system, wherein 
the transport protocol tunnel connection passes through a 
proxy server and a Web server, and wherein, m said trans- 
mitting the one or more transport protocol packets to the 
broker via the transport protocol tunnel connection, the 
program instructions are further computer-executable to 
implement: 

transmitting the one or more transport protocol packets 
from the client to the proxy server; 

transmitting the one or more transport protocol packets 
from the proxy server to the Web server; and 

the Web server forwarding the one or more transport 
protocol packets to the broker; 
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wherein the transport protocol tunnel connection passes 
through at least one firewall between the proxy server 
and the Web server. 

83. The carrier medium as recited in claim 80, wherein the 
acknowledgement transport protocol packet includes infor- 
mation indicating available space in the receive biifi:er, and 
wherein the program instructions are further computer- 
executable to implement: 

receiving the transmitted one or more transport protocol 
packets on the second node; 

storing the messaging system message from the one or 
more transport protocol packets in a receive buffer on 
the second node; 

generating on the second node an acknowledgement 
transport protocol packet to indicate successful receipt 
of the one or more transport protocol packets including 
the messaging system message; 

transmitting the acknowledgement transport protocol 
packet to the first node via the transport protocol tunnel 

receiving the transmitted acknowledgement transport pro- 
tocol packet on the first node; 

generating one or more messaging system messages on 
the first node; 

storing the one or more messaging system messages in a 
transmit buffer on the first node; 

determining from the information indicating available 
space in the receive bufter included in the received 
acknowledgement transport protocol packet that there 
is space available to receive the one or more messaging 
system messages on the second node; 

generating a second one or more transport protocol pack- 
ets, wherein the second one or more transport protocol 
packets include the one or more messaging system 
messages; and 

transmittmg the second one or more transport protocol 
packets to the second node via the transport protocol 

84. The carrier medium as recited in claim 80, wherein the 
first node is a client in the messaging system, wherein the 
transport protocol tunnel connection passes through a Web 
server, and wherein the program instructions are further 
computer-executable to implement: 

receiving the transmitted one or more transport protocol 
packets on the second node; 

storing the messaging system message from the one or 
more transport protocol packets in a receive buffer on 
the second node; 

the second node generating an acknowledgement trans- 
port protocol packet to indicate successful receipt of the 
one or more transport protocol packets including the 
messaging system message; 



transmitting the acknowledgement transport protocol 
packet to the Web server; 

storing the acknowledgement transport protocol packet in 
a transport protocol packet buffer on the Web sen'er; 

the client sending a transport protocol request packet to 
the Web ser\'er; and 

the Web server transmitting the acknowledgement trans- 
port protocol packet stored in the transport protocol 
packet buffer to the client via the transport protocol 
tunnel connection in response to the transport protocol 
request packet. 

85. The carrier medium as recited in claim 80, wherein the 
first node is a broker in the messaging system, wherein the 
transport protocol tunnel connection passes through a Web 
server, and wherein the program instructions are further 
computer-executable to implement: 

receiving the transmitted one or more transport protocol 
packets on the second node; 

storing the messaging system message from the one or 
more transport protocol packets in a receive buffer on 
the second node; 

the second node generating an acknowledgement trans- 
port protocol packet to indicate successful receipt of the 
one or more transport protocol packets including the 
messaging system message; 

transmitting the acknowledgement transport protocol 
packet to the Web server; and 

the Web server forwarding the acknowledgement trans- 
port protocol packet to the first node via a Transmission 
Control Protocol (TCP) connection portion of the trans- 
port protocol tunnel connection. 

86. The carrier medium as recited in claim 80, wherein the 
second node is a client in the messaging system, wherein the 
transport protocol tunnel connection passes through a Web 
server, and wherein, in said transmitting the one or more 
transport protocol packets to the second node via the trans- 
port protocol tunnel connection, the program instructions are 
further computer-executable to implement: 

transmitting the one or more transport protocol packets to 

the Web server; 
storing the one or more transport protocol packets in a 

transport protocol packet bufter on the Web server; 
the client sending one or more transport protocol request 

packets to the Web server; and 
the Web server transmitting the one or more transport 

protocol packets stored in the transport protocol packet 

buffer to the client via the transport protocol tunnel 

connection in response to the one or more transport 

protocol request packets. 

87. The carrier medium as recited in claim 80, wherein the 
transport protocol is Hypertext Transport Protocol (HTTP). 
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(57) ABSTRACT 

A conventionally coded application conversion system for 
streamed delivery and execution converts locally installable 
applications into a data set suitable lor streaming over a 
network. The invention monitors two classes ol information 
during an application installation on a local computer sys- 
tem. System registry modifications are monitored and the 
modification data are recorded when the installation pro- 
gram writes to the registry ol the local computer system. File 
modification data are logged each time an installation pro- 
gram modifies a file on the system. This data is used to create 
an initialization data set which is the first set ol data to be 
streamed Irom the server to the client and contains the 
information captured needed by the client to prepare the 
client machine lor streaming a particular appKcation. A 
runtime data set is also created that contains the rest ol the 
data that is streamed to the client once the client machine is 
initialized lor a particular application. A versioning table 
contains a list ol root file numbers and version numbers 
which are used to track application patches and upgrades. 
The invention monitors a running application that is being 
configured for a particular working environment on the local 
computer system. The data acquired are used to duphcate the 
same configuration on muhiple client machines. 
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CONVENTIONALLY CODED APPLICATION 
CONVERSION SYSTEM FOR STREAMED 
DELIVERY AND EXECUTION 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

[0001] This application Claims benefit of U.S. Provisional 
Patent Application Serial No. 60/246,384, filed on Nov. 6, 
2000 (OTI.2000.0). 

BACKGROUND OF THE INVENTION 
[0002] f . Technical Field 

[0003] The invention relates to the streaming of computer 
program object code across a network in a computer envi- 
ronment. More particularly, the invention relates to stream- 
ing and execution of existing apphcations across a network 
of servers streaming computer program object code and 
other related data to clients in a computer environment. 

[0004] 2. Description of the Prior Art 

[0005] Retail sales models of computer application pro- 
grams are fairly straight forward. The consumer either 
purchases the application program from a retailer that is 
either a brick and mortar or an ecommerce entity. The 
product is delivered to the consumer in a shrink-wrap form. 

[0006] The consumer installs the program from a floppy 
disk or a CD-ROM included in the packaging. A serial 
number is generally provided that must be entered at instal- 
lation or the first time the program is run. Other approaches 
require that the CD-ROM be present whenever the program 
is run. However, CD-ROMs are easily copied using common 
CDR technology. 

[0007] Another approach is for the consumer to effectuate 
the purchase through an ecommerce entity. The apphcation 
program is downloaded in its entirety to the consumer across 
the Internet. The consumer is emailed a serial number that is 
required to run the program. The consumer enters the serial 
number at the time the program is installed or the first time 
the program is run. 

[0008] Once the application program is installed on a 
machine, it resides on the machine, occupying precious hard 
disk space, until it is physically removed. The installer 
portion of the program can also be installed on a server along 
with the installation files. Users within an intranet can install 
the program from the server, across the network, onto their 
machines. The program is a full installation of the program 
and resides on the user's machine until it is manuaUy 
removed. 

[0009] Trial versions of programs are also available online 
that are a partial or full installation of the apphcation 
program. The program executes normally for a preset time 
period. At the end of the time period, the consumer is told 
that he must purchase the program and execution is termi- 
nated. The drawback to this approach is that there is an easy 
way for the consumer to fool the program. The consumer 
simply uninstalls the program and then reinstalls it, thereby 
restarting the time period. 

[0010] Additionally, piracy problems arise once the appli- 
cation program is resident on the consumer's computer. 
Serial numbers for programs are easily obtained across the 
Internet. Software companies lose billions of dollars a year 
in revenue because of this type of piracy. 



[0011] The above approaches fail to adequately protect 
software companies' revenue stream. These approaches also 
require the consumer to install a program that resides 
indefinitely on the consumer's hard disk, occupying valu- 
able space even though the consumer may use the program 
infrequently. 

[0012] The enterprise arena allows Apphcation Service 
Providers (ASP) to provide browser-based implementations 
such as Tarantella offered by Santa Cruz Operation, Inc. in 
Santa Cruz, Calif, and Metaframe offered by Citrix Systems 
Inc. of Fort Lauderdale, Fla. A remote apphcation portal site 
allows the user to click on an application in his browser to 
execute the application. The application runs on the portal 
site and GUI interfaces such as display, keystrokes and 
mouse clicks are transferred over the wire. The access to the 
program is password protected. This approach allows the 
provider to create an audit trail and to track the use of an 
application program. AppStream Inc. of Palo Alto, Calif, 
uses Java code streamlets to provide streaming applications 
to the user. The system partitions a Web application program 
into Java streamlets. Java streamlets are then streamed to the 
user's computer on an as-needed basis. The application nins 
on the user's computer, but is accessed through the user's 
network browser. 

[0013] The drawback to the browser-based approaches is 
that the user is forced to work within his network browser, 
thereby adding another layer of complexity. The browser or 
Java program manages the apphcation program's run-time 
environment. The user loses the experience that the software 
manufacturer had originally intended for its product includ- 
ing features such as apphcation invocation based on file 

[0014] It would be advantageous to provide a convention- 
ally coded application conversion system for streamed deliv- 
ery and execution that converts a conventionally coded 
application program into a streamed application suitable for 
concurrent execution on a chent while being streamed from 
a server. It would further be advantageous to provide a 
conventionally coded application conversion system for 
streamed delivery and execution that does not require the 
conventionally coded apphcation program to be recompiled 
or recoded. 

SUMMARY OF THE INVENTION 

[0015] The invention provides a conventionally coded 
application conversion system for streamed delivery and 
execution. The system converts a conventionally coded 
application program into a streamed application suitable for 
concurrent execution on a chent while being streamed from 
a server. In addition, the invention provides a system that 
does not require the conventionally coded application pro- 
gram to be recompiled or recoded. 

[0016] The invention converts locally installable apphca- 
tions into a data set suitable for streaming over a network. 
The invention monitors two classes of information during an 
application installation on a local computer system: system 
registry modifications and file modifications. 

[0017] To monitor system registry modifications, the 
invention records the modification data when the instaUation 
program writes to the registry of the local computer system, 
including registry key path, value name and value data is 
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recorded. File modification data are logged each time an 
installation program modifies a file on the system. The 
invention sorts this data and removes duplicates and param- 
eterizes all local-system-speciflc registry keys, value names, 
and values, so they can be recognized by the client instal- 
lation software. 

[0018] This data is used to create an initiaKzation data set 
which is the first set of data to be streamed from the server 
to the client. This data set contains the information captured 
needed by the client to prepare the client machine for 
streaming a particular application. A runtime data set is also 
created that contains the rest of the data that is streamed to 
the client once the client machine is initialized for a par- 
ticular application. The runtime data consists of all the 
regular application files and the directories containing infor- 
mation about those appKcation files. Each directory contains 
list of file name, file number, and the metadata associated 
with the files in that particular directory. 
[0019] A veisioning table contains a list of root file 
numbers and version numbers. This information is used to 
track application patches and upgrades. Each entry in the 
versioning table corresponds to one patch level of the 
application with a corresponding new root directory. The 
client is sent the versioning table and compares it with the 
client's application root file number to find the files required 
for a software patch or update. 

[0020] The invention monitors a running apphcation that 
is being configured for a particular working environment on 
the local computer system. Common configuration modifi- 
cations are captured and the data acquired are used to 
duplicate the same configuration on multiple client 
machines, making it unnecessary for each user to configure 
his/her own application installation. 

[0021] The invention monitors and profiles the sequence 
of file blocks accessed by the apphcation program as it runs. 
This information is used so that frequently used file blocks 
can be streamed to the client machine before other less used 
file blocks and cached locaUy on the client cache before the 
user starts using the streamed application for the first time. 
Additionahy, frequently accessed files can be reordered in 
the directories to allow faster lookup of the file information. 
Finally, the association of a set of file blocks with a par- 
ticular user input allows the client to prefetch from the 
server, a set of file blocks needed to respond to that particu- 

[0022] Other aspects and advantages of the invention will 
become apparent from the following detailed description in 
combination with the accompanymg drawmgs, illustrating, 
by way of example, the principles of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0023] FIG. 1 is a block schematic diagram of a preferred 
embodiment of the invention showing components on the 
server that deal with users subscribing to and running 
applications according to the invention; 
[0024] FIG. 2 is a block schematic diagram of a preferred 
embodiment of the invention showing the client components 
supporting application delivery and execution according to 
the invention; 

[0025] FIG. 3 is a block schematic diagram of a preferred 
embodiment of the invention showing the components 
needed to install applications on the client according to the 



[0026] FIG. 4 is a block schematic diagram of the Builder 
that takes an existing application and extracts the Applica- 
tion File Pages for that appKcation according to the inven- 

[0027] FIG. 5fl is a block schematic diagram illustrating 
how the Ghent Network Spooler is used to handle mapping 
TCP interfaces to HTTP interfaces according to the inven- 

[0028] FIG. 5b is a block schematic diagram illustrating 
how the Ghent Network Spooler is used to handle mapping 
TCP interfaces to HTTP interfaces according to the inven- 

[0029] FIG. 6a is a block schematic diagram showing 
several different components of the client software accord- 

[0030] FIG. (>h is a block schematic diagram showing the 
use of volatile and non-volatile storage of code and data in 
the cUent and server according to the invention; 
[0031] FIG. 7fl is a block schematic diagram showing one 
of two ways in which data may be compressed while in 
transit between the server and client according to the inven- 

[0032] FIG. 7b is a block schematic diagram showing the 
other way in which data may be compressed while in transit 
between the server and client according to the invention; 

[0033] FIG. 8 is a block schematic diagram showing an 
organization of the streaming client software according to 
the invention; 

[0034] FIG. 9 is a block schematic diagram showing an 
alternative organization of the streaming client software 
according to the invention; 

[0035] FIG. 10 is a block schematic diagram showing the 
application streaming software consisting of a streaming 
block driver according to the invention; 
[0036] FIG. 11 is a block schematic diagram showing the 
application streaming software has been divided into a disk 
driver and a user mode client according to the invention; 
[0037] FIG. 12 is a block schematic diagram showing the 
unencrypted and encrypted chent caches according to the 

[0038] FIG. 13 is a block schematic diagram showing an 
application generating a sequence of code or data requests to 
the operating system according to the invention; 
[0039] FIG. 14 is a block schematic diagram showing 
server-based prefetching according to the invention; 
[0040] FIG. 15 is a block schematic diagram showing a 
client-to-client communication mechanism that allows local 
application customization to travel from one client machine 
to another without involving server communication accord- 
ing to the invention; 

[0041] FIG. 16 is a block schematic diagram showing a 
client cache with extensions for supporting local file cus- 
tomization according to the invention; 
[0042] FIG. 17 is a block schematic diagram showing 
aspects of a preferred embodiment of the invention related 
to load balancing and hardware fail over according to the 
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[0043] FIG. 18 is a block schematic diagram showing the 
benefits to the use of compression in the streaming of 
Application File Pages according to the invention; 
[0044] FIG. 19 is a block schematic diagram showing 
pre-compression of Application File Pages according to the 

[0045] FIG. 20 is a block schematic diagram showing 
multi-page compression of Application File Pages according 
to the invention; 

[0046] FIG. 21 is a block schematic diagram showing 
profile-based prefetching according to the invention; 
[0047] FIG. 22 is a block schematic diagram showmg the 
use of tokens and a License Server according to the inven- 

[0048] FIG. 23 is a block schematic diagram showing a 
flowchart for the Builder Install Monitor according to the 

[0049] FIG. 24 is a block schematic diagram showing a 
flowchart for the Builder Application Profiler according to 
the invention; 

[0050] FIG. 25 is a block schematic diagram showing a 
flowchart for the Builder SAS Packager according to the 

[0051] FIG. 26a is a block schematic diagram showing 

versioning support according to the invention; 

[0052] FIG. 266 is a block schematic diagram showing 

versioning support according to the invention; 

[0053] FIG. 27 is a block schematic diagram showing a 

data flow diagram for the Streamed Application Set Builder 

according to the invention; 

[0054] FIG. 28 is a block schematic diagram showing the 
Streamed Application Set format according to the invention; 
[0055] FIG. 29 is a block schematic diagram showing an 
SAS client using a device driver paradigm according to the 

[0056] FIG. 30 is a block schematic diagram showing an 
SAS client using a file system paradigm according to the 

[0057] FIG. 31fl through 3ilh is a schematic diagram 
showing various components of the AppinstallBlock format 
according to the invention; 

[0058] FIG. 32 is a block schematic diagram showing the 
Application InstaU Block lifecycle according to the inven- 

[0059] FIG. 33 is a block schematic diagram showing 
peer caching according to the invention; 
[0060] FIG. 34 is a block schematic diagram showing 
proxy caching according to the invention; 

[0061] FIG. 35 is a block schematic diagram showing 
multicast within a LAN and a packet protocol according to 
the invention; 

[0062] FIG. 36 is a block schematic diagram showing 
concurrent requests for application server pages, for the case 
when the page is first requested through the proxy according 
to the invention; 



[0063] FIG. 37 is a block schematic diagram showing 
concurrent requests for application server pages, for the case 
when the page is first requested through the peer caching 
according to the invention; 

[0064] FIG. 38 is a block schematic diagram showing 
concurrent requests for application server pages, for the case 
when the page is received only through peer caching accord- 

[0065] FIG. 39 is a block schematic diagram showing a 
client-server system using peer and proxy caching according 
to the invention; 

[0066] FIG. 40 is a block schematic diagram showing a 
preferred embodiment of the invention preventing piracy of 
remotely served, locally executed appKcations according to 
the invention; 

[0067] FIG. 41 is a block schematic diagram showing the 
filtering of accesses to remote application files according to 
the invention; 

[0068] FIG. 42 is a block schematic diagram showing the 
filtering of accesses to remote files based on process code 
location according to the invention; 

[0069] FIG. 43 is a block schematic diagram showing the 
filtering of accesses to remote files based on targeted file 
section according to the invention; 

[0070] FIG. 44 is a block schematic diagram showing the 
filtering of accesses to remote files based on surmised 
purpose according to the invention; and 

[0071] FIG. 45 is a block schematic diagram showing the 
filtering of accesses to remote files based on past access 
history according to the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0072] The invention is embodied in a conventionally 
coded application conversion system for streamed delivery 
and execution in a computer environment. A system accord- 
ing to the invention converts a conventionally coded apph- 
cation program into a streamed application suitable for 
concurrent execution on a chent while being streamed from 
a server. In addition, the invention provides a system that 
does not require the conventionally coded application pro- 
gram to be recompiled or recoded. 

[0073] The invention provides a highly efficient and 
secure application delivery system in conjunction with the 
adaptively optimized execution of applications across a 
network such as the Internet, a corporate intranet, or a wide 
area network. This is done in such a way that existing 
applications do not need to be recompiled or recoded. 
Furthermore, the invention is a highly scalable, load-bal- 
ancing, and fault -tolerant system. 

[0074] When using the invention, an end-user requests 
applications that are resident on remote systems to be 
launched and run on the end-user's local system. The 
end-user's local system is called the client or chent system, 
e.g., a desktop, laptop, palmtop, or information appliance. A 
remote system is a called a server or server system and is 
located within a collection of one or more servers called a 
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[0075] From the point of view of the client system, the 
application appears to be installed locally on the client even 
though it was initially installed on a different computer 
system. The applications execute locally on the client system 
and not on the server system. To achieve this result, the 
application is converted into a form suitable for streaming 
over the network. The streaming-enabled form of an appli- 
cation is called the Streamed Application Set (SAS) and the 
conversion process is termed the SAS Builder. The conver- 
sion of an application into its SAS form typically takes place 
on a system different from either an end-user client system 
or an Application Service Provider Server Cluster. This 
system is called the SAS Conversion System or, simply, the 
conversion system. 

[0076] Components of the invention are installed on the 
client system to support activities such as the installation, 
invocation, and execution of a SAS-bascd application. Other 
components of the invention are installed on the server 
system to support activities such as the verification of end 
user application subscription and license data and the trans- 
fer and execution of a SAS-based application on the client 
system. Some of the chent and some of the server compo- 
nents run in the kernel-mode while other components run in 
the usual user-mode. 

[0077] The term Application Service Provider (ASP) 
refers to an entity that uses the server components on one or 
more server systems, i.e., an ASP Ser\'er Cluster, to deliver 
applications to end-user client systems. Such an entity could 
be, for example, a software manufacturer, an e-commerce 
vendor that rents or leases software, or a service department 
within a company. The invention enables an ASP to deliver 
applications across a network, in a highly efficient and 
secure way; the applications are adaptively optimized for 
execution on an end-user's client system. 

[0078] A number of techniques arc employed to increase 
the overall performance of the delivery of an appKcation and 
its subsequent execution by minimizing the effect of net- 
work latency and bandwidth. Among the techniques 
employed arc: the SAS Builder identifies sequences of 
frequently accessed application pages and uses this infor- 
mation when generating a SAS; individual SAS pages and 
sequences of SAS pages are compressed and cached in an 
in-mcmory cache on the server system; various aspects of 
the applications are monitored during their actual use on a 
client and the resulting profiling data is used by the client to 
pre-fetch (pull) and by the server to send (push) additional 
pages which have a high likelihood of being used prior to 
their actual use; and SAS pages are cached locally on a client 
for their immediate use when an application is invoked. 

[0079] Aggregate profile data for an application, obtained 
by combining the profile data from all the end-user client 
systems running the application, is used to increase the 
system performance as well. A number of additional caching 
techniques that improve both system scalability and perfor- 
mance are also employed. The above techniques are collec- 
tively referred to as collaborative caching. 

[0080] In an embodiment of the invention, the SAS 
Builder consists of three phases: instaUation monitoring, 
execution profiling, and application stream packaging. In the 
final SAS Builder phase, the Application Stream Packager 
takes the information gathered by the Application Install 
Monitor and the AppKcation Execution Profiler and creates 
the SAS form of the application, which consists of a Stream 
Enabled Application Pages File and a Stream Enabled 
Application InstaU Block. 



[0081] The Stream Enabled Application Install Block is 
used to install a SAS-based application on a client system 
while selected portions of the Stream Enabled Apphcation 
Pages File are streamed to a client to be run on the client 
system. The Stream Enabled Application Install Block is the 
first set of data to be streamed from the server to the client 
and contains, among other things, the information needed by 
the client system to prepare for the streaming and execution 
of the particular application. Individual and aggregate client 
dynamic profile data is merged into the existing Stream 
Enabled Application Install Block on the server to optimize 
subsequent streaming of the application. 
[0082] The invention employs a Client Streaming File 
System that is used to manage specific application-related 
file accesses during the execution of an apphcation. For 
example, there are certain shared library files, e.g., "foo.dll", 
that need to be installed on the local file system, e.g., 
"c:\winnf\system32\foo.dU", for the appKcation to execute. 
Such file names get added to a "spoof database". For the 
previous example, the spoof database would contain an 
entry saying that "c:\winnt\system32\foo.dll" is mapped to 
"z:\word\winnt\system32\foo.dU" where "z:" imphes that 
this file is accessed by the Chent Streaming File System. The 
Client Spoofer will then redirect all accesses to 
"c:\winnt\system32\foo.dll" to 
"z:\word\winnt\system32\foo.dU". In this manner, the cKent 
system gets the effect of the file being on the local machine 
whereas in reality the file is streamed from the server. 
Several different classes of files can be treated in this way, 
e.g., specific application registry entries and application- 
based networking calls when such calls cross a firewaU. 

[0083] Lastly, the invention incorporates a number of 
software anti-piracy techniques directed at combating the 
piracy of applications of the type described herein that are 
delivered to the end-user over a network for execution on a 
client system. Among the anti-piracy techniques included 
are: client-side fine-grained filtering of file accesses directed 
at remotely served files; filtering of file accesses based on 
where the code for the process thai originated the request is 
stored; identification of crucial portions of application files 
and filtering file access depending on the portions of the 
application targeted; filtering of file accesses based on the 
surmised purpose of the file access, as determined by 
examining the program stack or flags associated with the 
request; and filtering of file accesses based on the surmised 
purpose of the file access, as determined by examining a 
history of previous file accesses by the same process. 
[0084] As mentioned above, the invention provides server 
and client technology for streaming application delivery and 
execution. The invention includes secure license-based 
streaming delivery of applications over Internet/extranets/ 
intranets utilizing client-based execution with client caching 
and server-based file accesses by page. 

[0085] f . The invention provides many advantages over 
the present approaches, including: 

[0086] Secure license-based streaming delivery over Inter- 
net/extranets/intrancts: 

[0087] reduces IT costs over client installation; 

[0088] supports rental model of app delivery, which 
opens new markets and increases user convenience 
over purchase and client installation; and 

[0089] enhances the opportunities to prevent soft- 
ware piracy over purchase and chent installation. 
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[0090] Client-based execution with client caching: 

[0091] increases typical application performance 
over server-based execution; 

[0092] reduces network latency and bandwidth usage 
over non-cached client execution; and 

[0093] allows existing applications to be run w/o 
rewrite/reconipile/rebuild unlike other explicitly-dis- 
tributed client/server application delivery 
approaches. 
[0094] Server-based file accesses: 

[0095] improve server-scaling over server-based 

[0096] allow transparent failover to another server 
whereas server-based execution does not; 

[0097] make server load balancing easier than it is 
with server-based execution; and 

[0098] allow increased flexibility in server platform 
selection over server-based execution. 

[0099] Server-based file accesses by page: 

[0100] reduce network latency over complete file 
downloads; 

[0101] reduce network bandwidth overhead over 
complete file downloads; and 

[0102] reduce client cache footprint over complete 
file downloads. 

[0103] 2. Features of the Invention 

[0104] A) Server Components Supporting Apphcation 
Delivery and Execution 

[0105] i) referring to FIG. 1, the server components 
include: 

[0106] a. Client/server network interface 110 that is 
common to the client 113 and the server. This is the 
communication mechanism through which the client 
and the server communicate. 

[0107] b. The Subscription Server 105— This is the 
server the client 113 connects to for subscribing and 
unsubscribing applications. This server then adds/ 
deletes the subscription information to the Subscrip- 
tion Database 101 and also updates the License 
Database 102 with the information stating that the 
cKent 113 can/cannot run the subscribed information 
under the agreed upon licensing terms. This com- 
munication between the client 113 and the Subscrip- 
tion Server 105 happens over SSL that is an industry 
standard protocol for secure communication. The 
Subscription Server 105 is also contacted for updat- 
ing any existing subscription information that is in 
the Subscription Database 101. 

[0 1 08] c . ' rhe License Server 106— This is the server 
the client 113 connects to for getting a license to run 
an application after the client has subscribed to the 
application. Tliis server validates the user and his 
subscriptions by consulting the License Database 
102. If the client 113 does have a valid Kcense, the 
License Server 106 sends an "Access token" to the 



chent that is encrypted using an "encryption key" 
that the License Database 102 obtains from the 
Server Config Database 103. The "Access token" 
contains information like the Application ID and an 
expiration time. Along with the "Access token," the 
License Server 106 also sends a list of least loaded 
application servers that it obtains from the Server 
Config Database 103 and also the expiration time 
that was encoded in the "Access token". The client 
113 uses this expiration time to know when to ask for 
a new token. This communication between the client 
113 and the License Server 106 happens over SSL. 
[0109] d. The Apphcation Server 107— Once the 
client 113 obtains an "Access token" to run an 
application, it connects to the Application Server 107 
and presents to it the "Access token" along with the 
request for the apphcation bits. Note that the "Access 
token" is opaque to the client 113 since it does not 
have the key to decrypt it. The Application Server 
107 validates the "Access token" by decrypting it 
using a "decryption key" obtained from the Server 
Config Database 103 and checking the content 
against a predefined value like for example the 
Application ID and also by making sure that the 
expiration time in the "Access token" has not 
elapsed. It then serves the appropriate bits to the 
chent 113 to enable it to run the apphcation. The 
encryption and decryption keys could be something 
like a private key/public key pair or a symmetric key 
or any other means of providing security. Note that 
the keys are uniform across all the servers within an 
ASP. 

[0110] e. The Monitor Server 108— It monitors the 
load in terms of percent of CPU utihzation on the 
Application Servers 107 and the License Servers 106 
on a periodic basis (for example — every minute) and 
adds that information to the Server Config Database 
103. 

[0111] f. The Profile Server 109— it receives profile 
information from the clients periodically. It adds this 
information to the Profile Database 104. The Profile 
Server 109 based on the profile information from 
different clients updates the App Prefetch Page List 
section of the Stream App Install Blocks 112. 
[0112] ii) The data structures supporting the above 

server components include: 

[0113] a. Subscriphon Database 101— This is the 
database that stores the user information in terms of 
username, list of apps subscribed, password, billing 
information, address, group, admin. The username is 
the primary key. The admin field identifies if this 
user has admin privileges for the group he belongs 

[0114] b . License Database 102— Tliis is the database 
that stores licensing information, i.e., which user can 
run what apphcation and under which license. This 
database also keeps track of usage information, i.e., 
which user has used which apphcation for how long 
and how many times. The information looks like: 

[0115] Username, application, time of usage, num- 
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[0116] Username, appKcation, licensing policy 

[0117] Username, application, is app running, no 
of instances, time of start The username is the 
primary key. The licensing policy could be some- 
thing simple like expiry date or something more 
complicated like number of instances simulta- 
neously allowed within a group etc. 

[0118] c. Server Config Database 103— This data- 
base stores information about which server can run 
which application, what is the load on all the servers, 
what is the encryption "key" to be used by the 
servers and all other information that is needed by 
the servers. The information looks like: 

[0119] Server IP address, App/Slim server, appli- 
cation Kst, current load 

[0120] Encryption key. Decryption key The Server 
IP address is the primary key for the first table. 
The keys are common across all servers. 

[0121] d. Profile Database 104— This database stores 
the profile information received by the profile server 
from the clients periodically. The information looks 
like: 

[0122] Application ID, File ID, Block ID number 
of hits The Application ID is the primary key. 

[0123] e . Application File Pages 111— This is the one 
of the outputs of the "builder" as explained below 
and is put on the Application Server 107 so that it can 
serve the appropriate bits to the client. 

[0124] f . Stream App Install Blocks 112— This is the 
other output of the "builder" and contains the infor- 
mation for successfully installing applications on the 
client for streaming applications. 

[0125] B) Client Components Supporting Application 
Delivery & Execution 

[0126] i) With respect to FIGS. 1 and 2, these cHent 
components include: 

[0127] a . Client/Server Network interface 202— This 
is the same interface as explained above. 

[0128] b. Client License Manager 205— This com- 
ponent requests licenses ("Access tokens") from the 
License Server 106 when the client wants to run 
applications. The License Server 106 sends an 
"Access token" to the client that can be used to run 
the applications by presenting it to the Application 
Server 107. Along with the token, the License Server 
106 also sends the expiry time of the token. The 
Client License Manager 205 renews the token just 
before the expiry period so that the client can con- 
tinue running the application. When the appfication 
is complete, the Client License Manager 205 releases 
the token by sending a message to the License Server 
106. In addition, when a user has subscribed to an 
application, the Client License Manager 205 first 
checks to make sure that the application is installed 
on the machine the user is trying to mn the applica- 
tion from and if not requests for the application 
installation. It does this using a list of Installed Apps 
that it maintains. 



[0129] c. Client Cache Manager 207— This compo- 
nent caches the application bits received from the 
Application Server 107 so that next time a request is 
made to the same bits, the request can be served by 
the cache instead of having to go to the Application 
Ser\'er 107. The Client Cache Manager 207 has a 
limited amount of space on the disk of the client 
machine that it uses for the cache. When the space is 
fully occupied, the Client Cache Manager 207 uses 
a policy to replace existing portions of the cache. 
This policy can be something like LRU, FIFO, 
random etc. The Client Cache Manager 207 is 
responsible for getting the application bits requested 
by the Client Streaming File System 212. If it does 
not have the bits cached, it gets them from the 
Application Server 107 through the network inter- 
face. However it also need to get the "Access token" 
from the Client License Manager 205 that it needs to 
send along with the request for the application bits. 
The Client Cache Manager 207 also updates the 
Prefetch History Info 209 with the requests it 
receives from the Client Streaming File System 212. 

[0130] d. Client Streaming File System 212— This 
component serves all file system requests made by 
the application running on the client. The application 
makes calls like "read", "write" etc. to files that need 
to be streamed. These requests lead to page faults in 
the operating system and the page faults are handled 
by the Client Streaming File System 212 that in turn 
asks the Client Cache Manager 207 for the appro- 
priate bits. The Client Cache Manager 207 will send 
those bits from the cache if they exist there or 
forward the request to the Application Server 107 
through the network interface to get the appropriate 
bits. 

[0131] e. Client Prefetcher 208— This component 
monitors the requests made by the client to the 
Application Server 107 and uses heuristics to make 
additional requests to the Application Server 107 so 
that the bits can be obtained from the Application 
Server 107 before the client machine makes the 
request for them. This is mainly to hide the latency 
between the client and the Application Server 107. 
The history information of the requests is stored in 
the Prefetch History Info file 209. 

[0132] f. Client Profiler 203— At specific time inter- 
vals, the client profiler sends the profile information, 
which is the Prefetch History Info to the prefetch 
server at the ASP that can then update the App 
Prefetch Page Lists for the difterent applications 
accordingly. 

[0133] g. Client File Spoofer 211— Certain files on 
the client need to be installed at specific locations on 
the client system. To be able to stream these files 
from the Application Server 107, the Client Spoofer 
211 intercepts all requests to these files made by a 
running application and redirects them to the Client 
Streaming File System 212 so that the bits can be 
streamed from the Application Server 107. 

[0134] h. Client Registry Spoofer 213— Similar to 
files, certain registry entries need to be different 
when the application being streamed is running and 
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since it is undesirable to overwrite the existing 
registry value, the read of the registry value is 
redirected to the Client Registry Spoofer 215 which 
returns the right value. However, this is optional as 
it is very likely that overwriting the existing registry 
value will make the system work just fine. 

[0135] i. Client Network Spoofer 213— Certain 
applications make networking calls through a pro- 
tocol like TCP. To make these applications work 
across firewalls, these networking calls need to be 
redirected to the Client Network Spoofer 213 which 
can tunnel these requests through a protocol like 
HTTP that works through firewalls. 

[0136] ii) The data structures needed to support the 
above client components include: 

[0137] a. File Spoof Database 210— The hst of files 
the requests to which need to be redirected to the 
Client Streaming File System 212. This information 
looks like (The source file name is the primary key) 

[0138] Source File Name, Target File Name 
[0139] b. Registry Spoof Database 216— List of reg- 
istry entries and their corresponding values that need 
to be spoofed. Each entry looks like: 

[0140] Registry entry, new value 

[0141] c. Network Spoof Database 214— Like of IP 
addresses, the networking connections to which need 
to be redirected to the Client Network Spoofer 213. 
Each entry looks like (IP address is the primary key): 
[0142] IP address. Port number, new IP address, 
new Port number 

[0143] d. Client Stream Cache 206— The on-disk 
cache that persistently stores application bits. 

[0144] 6 . Kjiown ASPs and Installed Apps 204— The 
list of ASP servers (Application, License and Sub- 
scription) and also the list of applications that are 
installed on the client. 

[0145] f. Prefetch History Info 209— The history of 
the requests made to the cache. This consists of 
which blocks were requested from which file for 
which application and how many times each block 
was requested. It also consists of predecessor-suc- 
cessor information indicating which block got 
requested after a particular block was requested. 

[0146] C) Client Application Installation 
[0147] Referring to FIG. 3, the client appHcation instal- 
lation components include: 

[0148] i) Client License Manager 303— This is the 
same component explained above. 

[0149] ii) Client Application Installer 305— This 
component is invoked when the application needs to 
be installed. The Client AppKcation Installer 305 
sends a specific request to the Application Server 107 
for getting the Stream App Install Block 301 for the 
particular application that needs to be installed. Tlie 
Stream App Install Block 301 consists of the App 
Prefetch Page List 306, Spoof Database 308, 309, 
310, and App Registry Info 307. The Client AppH- 



cation Installer 305 then updates the various Spoof 
Databases 308, 309, 310 and the Registry 307 with 
this information. It also asks the Client Prefetcher 
208 to start fetching pages in the App Prefetch Page 
List 306 from the AppKcation Server 107. These are 
the pages that are known to be needed by a majority 
of the users when they run this application. 
[0150] D) Application Stream Builder Input/Output 

[0151] With respect to FIG. 4, the Builder components 
include the following: 

[0152] i) Application Install Monitor 403— This 
component monitors the installation of an applica- 
tion 401 and figures out all the files that have been 
created during installation 402, registry entries that 
were created and all the other changes made to the 
system during installation. 

[0153] ii) AppKcation Profiler 407— After the apph- 
cation is installed, it is executed using a sample 
script. The Application Profiler 407 monitors the 
application execution 408 and figures out the appli- 
cation pages that got referenced during the execu- 

[0154] iii) App Stream Packager 404— The App 
Stream Packager 404 takes the information gathered 
by the Application Profiler 407 and the AppKcation 
Install Monitor 403 and forms the Application File 
Pages 406 and the Stream App InstaK Block 405 
from that information. 

[0155] E) Network Spoofing for CKent-server Applica- 

[0156] Referring to FIGS. 1, 4, 5fl, 5b, and 6a, the 
component that does the Network Spoofing is the TCP to 
HTTP converter 503, 507. The basic idea is to take TCP 
packets and tunnel them through HTTP on one side and do 
exactly the opposite on the other. As far as the client 501 and 
the server 502 are concerned the communication is TCP and 
so existing applications that run with that assumption work 
unmodified. This is explained in more detail below. 
[0157] On the client side, the user launches an appKcation 
that resides on the CKent Streaming File System. That 
application may be started in the same ways that applica- 
tions on other client file systems may be started, e.g., 
opening a data file associated with the application or select- 
ing the application from the Start/Programs menu in a 
Windows system. From the point of view of the client's 
operating system and from the point of view of the appK- 
cation itself, tKat application is located locally on the client. 

[0158] WKenever a page fault occurs on bebalf of any 
application file residing on the Client Streaming File System 
604, that file system requests the page from the Client Cache 
Manager 606. TKe Client CacKe Manager 606, after ensuring 
via interaction witK tKe Client License Manager 608 that the 
user's client system holds a license to run the application at 
tKe current time, cKecks tKe Client Stream CacKe 611 and 
satisfies tKe page fault from tKat cacKe, if possible. If the 
page is not currently in the Client Stream CacKe 611, the 
Client CacKe Manager 606 makes a request to tKe Client/ 
Server Network Interface 505, 609 to obtain tKat page from 
tKe Application File Pages stored on an Application Server 
506. 
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[0159] The Client Prefetcher 606 tracks all page requests 
passed to the Ghent Cache Manager 606. Based on the 
pattern of those requests and on program locality or program 
history, the Chent Prefetcher 606 asks the Client Cache 
Manager 606 to send additional requests to the Chent/Server 
Network Interface 505, 609 to obtain other pages from the 
Application File Pages stored on the Application Server 506. 
[0160] Files located on the Client Streaming File System 
604 are typically identified by a particular prefix (like drive 
letter or pathname). However, some files whose names 
would normally imply that they reside locally are mapped to 
the Client Streaming File System 604, in order to lower the 
invention's impact on the user's local configuration. For 
instance, there are certain shared library files (dll's) that 
need to be installed on the local file system 
(c:\winnt\system32\foo.dll). It is undesirable to add that file 
on the user's system. The file name gets added to a "spoof 
database" which contains an entry saying that 
c:\winnt\system32\foo.dll is mapped to 

z:\word\winnt\system32\foo.dll where z: impKes that it is 
the Client Streaming File System. The Client Spooler 603 
will then redirect all accesses to c:\winnt\system32\foo.dll to 
z:\word\winnt\system32\foo.dll. In this manner the cHent 
system gets the effect of the file being on the local machine 
whereas in reality the file is streamed from the server. 
[0161] In a similar fashion the Client Spoofer 603 may 
also be used to handle mapping TCP interfaces to HTTP 
interfaces. There are certain client-server apphcations (like 
ERP/CRM applications) that have a component running on 
a chent and another component running on a database server, 
Web server etc. These components talk to each other through 
TCP connections. The client application wiU make TCP 
connections to the appropriate server (for this example, a 
database server) when the client piece of this apphcation is 
being streamed on a user's machine. 

[0162] The database server could be resident behind a 
firewaU and the only way for the client and the server to 
communicate is through a protocol like HTTP that can pass 
through firewalls. To enable the client to communicate with 
the database server, the client's TCP requests need to be 
converted to HTTP and sent to the database server. Those 
requests can be converted back to TCP so that the database 
server can appropriately process the requests just before the 
requests reach the database server. The Client Spoofer's 603 
responsibility in this case is to trap all TCP requests going 
to the database server and convert it into HTTP requests and 
take all HTTP requests coming from the database server and 
convert them into TCP packets. Note that the TCP to HUTP 
converters 505, 507 convert TCP traffic to HTTP and vice 
versa by embedding I'CP packets within the H'lT'P protocol 
and by extracting the TCP packets from the HTTP traffic. 
This is called tunneling. 

[0163] When the Client License Manager 608 is asked 
about a client's status with respect to holding a license for 
a particular application and the hcense is not already being 
held, the Client License Manager 608 contacts the License 
Server 106 via the Chent/Server Network Interface 609 and 
asks that the client machine be given the license. The 
License Server 106 checks the Subscription 101 and License 
102 Databases and, if the user has the right to hold the 
hcense at the current time, it sends back an Access Token, 
which represents the right to use the license. This Access 
Token is renewed by the chent on a periodic basis. 



[0164] The user sets up and updates his information in the 
Subscription 101 and License 102 Databases via interacting 
with the Subscription Server 105. 

[0165] Whenever a user changes his subscription infor- 
mation, the Subscription Server 105 signals the user's client 
system since the client's Known ASPs and Installed Apps 
information potentially needs updating. The client system 
also checks the Subscription 101 and License 102 Databases 
whenever the user logs into any of his chent systems set up 
for Streaming Apphcation Delivery and Execution. If the 
user's subscription list in the Subscription 101 and License 
102 Databases fist applications that have not been installed 
on the user's client system, the user is given the opportunity 
to choose to install those applications. 
[0166] Whenever the user chooses to install an applica- 
tion, the Client License Manager 608 passes the request to 
the Client Application Installer 607 along with the name of 
the Stream App InstaU Block to be obtained from the 
Application Server 107. The Client Application Installer 607 
opens and reads that file (which engages the Chent Stream- 
ing File System) and updates the Client system appropri- 
ately, including setting up the spoof database, downloading 
certain needed non-apphcation-specific files, modifying the 
registry file, and optionally providing a list of applications 
pages to be prefetched to warm up the Chent Stream Cache 
611 with respect to the application. 

[0167] The Apphcation Stieam Builder creates the Stieam 
App Install Block 405 used to set up a client system for 
Streaming Application Delivery and Execution and it also 
creates the set of Application File Pages 406 sent to satisfy 
client requests by the Application Server 107. The process 
that creates this information is offline and involves three 
components. I'he Apphcation Install Monitor 403 watches a 
normal installation of the application and records various 
information including registry entries, required system con- 
figuration, file placement, and user options. The Apphcation 
Profiler 407 watches a normal execution of the apphcation 
and records referenced pages, which may be requested to 
pre-warm the client's cache on behalf of this application. 
The Application Stream Packager 404 takes information 
from the other two Builder components, plus some infor- 
mation it compiles with respect to the layout of the installed 
application and forms the App Install Block 405 and the set 
of Apphcation File Pages 406. 

[0168] Server fail-over and server quality of service prob- 
lems are handled by the client via observation and informa- 
tion provided by the server components. An ASP's Sub- 
scription Server provides a list of License Servers associated 
with that ASP to the client, when the user initiates/modifies 
his account or when the client software explicitiy requests a 
new list. A License Server provides a list of Application 
Servers associated with an application to the client, when- 
ever it sends the client an Access Token for the application. 

[0169] Should the client observe apparent non-response or 
slow response from an Application Server, it switches to 
another Apphcation Server in its hst for the application in 
question. If none of the Apphcation Servers in its list 
respond adequately, the client requests a new set for the 
application from a License Server. The strategy is similar in 
the case in which the client observes apparent non-response 
or slow response from a License Server; the client switches 
to another License Server in its list for the ASP in question. 
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If none of the License Servers in its hst responds adequately, 
the client requests a new set of License Servers from the 
ASP. 

[0170] Server load balancing is handled by the server 
components in cooperation with the client. A server monitor 
component tracks the overall health and responsiveness of 
all servers. When a server is composing one of the server 
lists mentioned in the previous paragraph, it selects a set that 
is alive and relatively more lightly used than others. Client 
cooperation is marked by the client using the server lists 
provided by the servers in the expected way, and not 
unilaterally doing something unexpected, like continuing to 
use a server which does not appear in the most recent Kst 
provided. 

[0171] Security issues associated with the server client 
relationship are considered in the invention. To ensure that 
the communication between servers and clients is private 
and that the servers in question are authorized via appropri- 
ate certification, an SSL layer is used. To ensure that the 
clients are licensed to use a requested appKcation, user 
credentials (username+password) are presented to a License 
Server, which validates the user and his licensing status with 
respect to the application in question and issues an Access 
Token, and that Access Token is in turn presented to an 
Application Server, which verifies that the Token's validity 
before delivering the requested page. Protecting the appli- 
cation in question from piracy on the chent's system is 
discussed in another section, below. 

Client-side Performance Optimization 

[0172] This section focuses on client-specific portions of 
the invention. The invention may be apphed to any operating 
system that provides a file system interface or block driver 
interface. A preferred embodiment of the invention is Win- 
dows 2000 comphant. 

[0173] With respect to FIG. 6a, several different compo- 
nents of the client software are shown. Some components 
will typically run as part of the operating system kernel, and 
other portions will run in user mode. 

[0174] The basis of the cKent side of the streamed apph- 
cation delivery and execution system is a mechanism for 
making applications appear as though they were installed on 
the client computer system without actually installing them. 
[0175] Installed applications are stored in the file system 
of the client system as files organized in directories. In the 
state of the art, there are two types of file systems: local and 
network. Local file systems are stored entirely on media 
(disks) physically resident in the client machine. Network 
file systems are stored on a machine physicafiy separate 
from the client, and all requests for data are satisfied by 
getting the data from the server. Network file systems are 
typically slower than local file systems. A traditional 
approach to use the better performance of a local file system 
is to install important applications on the local file system, 
thereby copying the entire application to the local disk. The 
disadvantages of this approach are ntunerous. Large appli- 
cations may take a significant amount of time to download, 
especially across slower wide area networks. Upgrading 
applications is also more difBcult, since each cfient machine 
must individually be upgraded. 

[0176] The invention eliminates these two problems by 
providing a new type of file system: a streaming file system. 
The streaming file system allows appfications to be run 



immediately by retrieving application file contents from the 
server as they are needed, not as the application is installed. 
This removes the download cost penalty of doing local 
instaUations of the apphcation. The streaming file system 
also contains performance enhancements that make it supe- 
rior to running applications directly from a network file 
system. The streaming file system caches file system con- 
tents on the local machine. File system accesses that hit in 
the cache are nearly as fast as those to a local file system. 
The streaming file system also has sophisticated information 
about application file access patterns. By using this knowl- 
edge, the streaming file system can request portions of 
application files from the server in advance of when they 
will actually be needed, thus further improving the perfor- 
mance of applications running on the application streaming 
file system. 

[0177] In a preferred embodiment of the invention, the 
application streaming file system is implemented on the 
client using a file system driver and a helper apphcation 
running in user mode. The file system driver receives all 
requests from the operating system for files belonging to the 
application streaming file system. The requests it handles are 
all of the standard file system requests that every file system 
must handle, including (but not limited to) opening and 
closing files, reading and writing files, renaming files, and 
deleting files. Each file has a unique identifier consisting of 
an apphcation number, and a file number within that apph- 
cation. In one embodiment of the invention, the apphcation 
number is f 28 bits and the file number is 32 bits, resulting 
in a unique file ID that is 160 bits long. The file system driver 
is responsible for converting path names (such as 
"z:\program filcs\foo.exe") into file IDs (this is described 
below). Once the file system driver has made this transla- 
tion, it basically forwards the request to the user-mode 
program to handle. 

[0178] The user-mode program is responsible for manag- 
ing the cache of application file contents on the local file 
system and contacting the application streaming ser\'er for 
file contents that it cannot satisfy out of the local cache. For 
each file system request, such as read or open, the user-mode 
process wiU check to see if it has the requested information 
in the cache. If it does, it can copy the data from the cache 
and return it to the file system driver. If it does not, it 
contacts the application streaming server over the network 
and obtains the information it needs. To obtain the contents 
of the file, the user-mode process sends the file identifier for 
the file it is interested in reading along with an offset at 
which to read and the number of bytes to read. The appli- 
cation streaming server will send back the requested data. 

[0179] The file system can be implemented using a frag- 
mented functionality to facilitate development and debug- 
ging. All of the functionahty of the user-mode component 
can be put into the file system driver itself without signifi- 
cantly changing the scope of the invention. Such an 
approach is believed to be preferred for a client running 
Windows 95 as the operating system. 

[0180] Directories are speciaUy formatted files. The file 
system driver reads these from the user mode process just 
like any other files with reads and writes. Along with a 
header containing information about the directory (such as 
how long it is), the directory contains one entry for each file 
that it contains. Each entry contains the name of the file and 
its file identifier. The file identifier is necessary so that the 
specified file can be opened, read, or written. Note that since 
directories are files, directories may recursively contain 
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other directories. All files in an application streaming file 
system are eventual descendents of a special directory called 
the "root". The root directory is used as the starting point for 
parsing file names. 

[0181] Given a name lilte "z:/foo/bar/baz", the file system 
driver must transiate the path "z:/foo/bar/baz" into a fife 
identifier that can be used to read the fife from the appfica- 
tion streaming service. First, the drive fetter is stripped off. 
feaving "/foo/bar/baz". The root directory wiff be searched 
for the first part of the path, in this case "foo". If the fife 
"foo" is found in the root directory, and the fife "foo" is a 
directory, then "foo" wilf be searched for the next portion of 
the path, "bar". The fife system driver achieves this by using 
the fife id for "foo" (found by searching the root directory) 
to open the fife and read its contents. Tfie entries inside "foo" 
are then searched for "bar", and this process continues untif 
the entire path is parsed, or an error occurs. 

[0182] In the foffowing exampfes and text, the root direc- 
tory is focaf and private to the cfient. Each appfication that 
is instaffed wiff have its own speciaf subdirectory in the root 
directory. This subdirectory wiff be the root of the appfica- 
tion. Each appfication has its own root directory. 

[0183] The invention's approach is much more efedent 
than other approaches like the standard NFS approach. In 
those cases, the client sends the entire path "/foo/bar/baz" is 
sent to the server and the server returns the fife id for that fife. 
Next time there is a request for "/foo/bar/baz2" again the 
entire path needs to be sent. In the approach described here, 
once the request for "bar" was made, the fife ids for aff files 
within bar are sent bacls including the ids for "baz" and 
"baz2" and hence "baz2" will already be Icnown to client. 
This avoids communication between the chent and the 



[0184] In addition, this structure also affows appfications 
to be easify updated. If certain code segments need to be 
updated, then the code segment fisting in the appfication root 
directory is simpfy changed and the new code segment 
subdirectory added. This resufts in the new and correct code 
segment subdirectory being read when it is referenced. For 
example if a fife by the name of "/foo/bar/baz3" needs to be 
added, the root directory is simply changed to point to a new 
version of "foo" and that new version of "foo" points to a 
new version of "bar" which contains "baz3" in addition to 
the fifes it afready contained. However the rest of the system 
is unchanged. 

[0185] Cfient Features 

[0186] Referring to FIGS. (,a and 6b, a liey aspect of the 
preferred embodiment of the invention is that appfication 
code and data are cached in the cfient's persistent storage 
616, 620. This caching provides better performance for the 
cfient, as accessing code and data in the cfient's persistent 
storage 620 is typicaffy much faster than accessing that data 
across a wide area networli. This caching also reduces the 
foad on the server, since the client need not retrieve code or 
data from the application server that it afready has in its locaf 
persistent storage. 

[0187] In order to run an appfication, its code and data 
must be present in tfie cfient system's vofatife storage 619. 
The chent software maintains a cache of application code 
and data that normaffy reside in the cfient system's non- 
volatife memory 620. When the running appfication requires 



data that is not present in vofatife storage 619, the client 
streaming software 604 is aslied for the necessary code or 
data. The cfient software first checlis its cache 611, 620 in 
nonvofatife storage for the requested code or data, ff it is 
found there, the code or data are copied from the cache in 
nonvofatife storage 620 to vofatife memory 619. If the 
requested code or data are not found in the nonvofatife cache 
611, 620, the cfient streaming software 604 wilf acquire the 
code or data from the server system via the client's network 
interface 621, 622. 

[0188] Application code and data may be compressed 623, 
624 on the server to provide better client performance over 
slow networks. Network file systems typically do not com- 
press the data they send, as they are optimized to operate 
over local area networks. 

[0189] FIGS. 7fl & lb demonstrate two ways in which 
data may be compressed while in transit between the server 
and client. With either mechanism, the chent may request 
multiple pieces of code and data from multiple fifes at once. 
FIG. 7A iffustrates the server 701 compressing the concat- 
enation of A, B, C, and D 703 and sending this to the client 
702. FIG. 7B iflustrates the server 706 separately compress- 
ing A, B, C, and D 708 and sending the concatenation of 
these compressed regions to the cfient 707. fn either case, the 
cfient 702, 707 wifl decompress the bfocks to retrieve the 
original contents A, B, C, and D 704, 709 and these contents 
wiff be stored in the cache 705, 710. 

[0190] The boxes marked "Compression" represent any 
method of making data more compact, incfuding software 
afgorithms and hardware. The boxes marked "Decompres- 
sion" represent any method for expanding the compacted 
data, incfuding software afgorithms and hardware. The 
decompression afgorithm used must correspond to the com- 
pression afgorithm used. 

[0191] The mechanism for streaming of appfication code 
and data may be a fife system. Many network fife systems 
exist. Some are used to provide access to appfications, but 
such systems typicaffy operate weff over a focaf area net- 
work (LAN) but perform poorfy over a wide area network 
(WAN). White this sofution invofves a fife system driver as 
part of tlie cfient streaming software, it is more of an 
appfication defivery mechanism than an actuaf fife system. 

[0192] With respect to FIG. 8, appfication code and data 
are instaUed onto the fife system 802, 805, 806, 807 of a 
cfient machine, but they are executed from the vofatife 
storage (main memory). This approach to streamed appfi- 
cation defivery invofves instaffing a speciaf appfication 
streaming fife system 803, 804. To tfie cfient machine, the 
streaming fife system 803, 804 appears to contain the 
instaffed appfication 801. The appfication streaming fife 
system 803 wiff receive ail requests for code or data that are 
part of the appfication 801. This fife system 803 wfif satisfy 
requests for appfication code or data by retrieving it from its 
speciaf cache stored in a native fife system or by retrieving 
it directfy from the streaming appfication server 802. Code 
or data retrieved from the server 802 wiff be pfaced in the 
cache in case it is used again. 

[0193] Referring to FIG. 9, an afternative organization of 
the streaming cfient software is shown. The cfient software 
is divided into the kernef-mode streaming fife system driver 
905 and a user-mode cfient 902. Requests made to the 
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streaming file system driver 905 are all directed to the 
user-mode client 902, which handles the streams from the 
application streaming ser\'er 903 and sends the results back 
to the driver 905. The advantage of this approach is that it 
is easier to develop and debug compared with the pure- 
kernel mode approach. The disadvantage is that the perfor- 
mance will be worse than that of a kernel-only approach. 

[0194] As shown in FIGS. 10 and 11, the mechanism for 
streaming of application code and data may be a block driver 

1004, 1106. This approach is an akernative to that repre- 
sented by FIGS. 8 and 9. 

[0195] With respect to FIG. 10, the application streaming 
software consists of a streaming block driver 1004. This 
block driver 1004 provides the abstraction of a physical disk 
to a native file system 1003 already installed on the client 
operating system 1002. The driver 1004 receives requests 
for physical block reads and writes, which it satisfies out of 
a cache on a standard file system 1003 that is backed by a 
physical disk drive 1006, 1007. Requests that cannot be 
satisfied by the cache go to the streaming application server 

1005, as before. 

[0196] Referring to FIG. 11, the application streaming 
software has been divided into a disk driver 1106 and a user 
mode chent 1102. In a manner similar to that of FIG. 9, the 
disk driver 1106 sends all requests it gets to the user-mode 
chent 1102, which satisfies them out of the cache 1107, 1108 
or by going to the appKcation streaming server 1103. 

[0197] The persistent cache may be encrypted with a key 
not permanently stored on the client to prevent unauthorized 
use or duplication of application code or data. Traditional 
network file systems do not protect against the unauthorized 
use or duplication of file system data. 

[0198] With respect to FIG. 12, unencrypted and 
encrypted client caches. A, B, C, and D 1201 representing 
blocks of application code and data in their natural form are 
shown. E]^(X) represents the encryption of block X with key 
k 1202. Any encryption algorithm may be used. The key k 
is sent to the client upon application startup, and it is not 
stored in the application's persistent storage. 

[0199] Client-initiated prefetching of application code and 
data helps to improve interactive application performance. 
Traditional network file systems have no prefetching or 
simple locality based prefetching. 

[0200] Referring to FIG. 13, the application 1301 gener- 
ates a sequence of code or data requests 1302 to the 
operating systcm(OS) 1303. The OS 1303 directs these 1304 
to the client application streaming software 1305. The client 
software 1305 will fetch the code or data 1306 for any 
requests that do not hit in the cache from the server 1307, via 
the network. The client software 1305 inspects these 
requests and consults the contents of the cache 1309 as well 
as historic information about application fetching patterns 
1308. It will use this information to request additional blocks 
of code and data that it expects will be needed soon. This 
mechanism is referred to as "pull prefetching." 

[0201] Server-initiated prefetching of application code 
and data helps to improve interactive application perfor- 
mance. Traditional network file systems have no prefetching 
or simple locality based prefetching. 



[0202] With respect to FIG. 14, the server-based prefetch- 
ing is shown. As in FIG. 13, the client application streaming 
software 1405 makes requests for blocks 1407 from the 
apphcation streaming server 1408. The server 1408 exam- 
ines the patterns of requests made by this cKent and selec- 
tively returns to the client additional blocks 1406 that the 
client did not request but is likely to need soon. This 
mechanism is referred to as "push prefetching." 

[0203] A client-to-client communication mechanism 
allows local application customization to travel from one 
client machine to another without involving server commu- 
nication. Some operating systems have a mechanism for 
copying a user's configuration and setup to another machine. 
However, this mechanism typically doesn't work outside of 
a single organization's network, and usually will copy the 
entire environment, even if only the settings for a single 
application are desired. 

[0204] Referring to FIG. 15, a client-to-client mechanism 
is demonstrated. When a user wishes to run an application on 
a second machine, but wishes to retain customizations made 
previously on the first, the client software will handle this by 
contacting the first machine to retrieve customized files and 
other customization data. Unmodified files will be retrieved 
as usual from the application streaming server. 

[0205] Here, File 4 exists in three different versions. The 
server 1503 provides one version of this file 1506, client 
11501 has a second version of this flic 1504, and client 
21502 has a third version 1505. Files may be modified 
differently for each cKent. 

[0206] The clients may also contain files not present on the 
server or on other clients. File 51507 is one such file; it exists 
only on chent 11501. File 61508 only exists on client 21502. 

[0207] Local Customization 

[0208] A local copy-on-write file system allows some 
applications to write configuration or initialization files 
where ihey want to without rewriting the application, and 
without disturbing the local customization of other clients. 
Installations of appKcations on file servers typically do not 
allow the installation directories of applications to be writ- 
ten, so additional reconfiguration or rewrites of applications 
are usually necessary to allow per-user customization of 
some settings. 

[0209] With respect to FIG. 16, the cache 1602 with 
extensions for supporting local file customization is shown. 
Each block of data in the cache is marked as "clean"1604 or 
"dirty"1605. Pages marked as dirty have been customized 
by the client 1609, and cannot be removed from the cache 
1602 without losing client customization. Pages marked as 
clean may be purged from the cache 1602, as they can be 
retrieved again from the server 1603. The index 1601 
indicates which pages are clean and dirty. In FIG. 16, clean 
pages are white, and dirty pages are shaded. File 11606 
contains only clean pages, and thus may be entirely evicted 
from the cache 1602. File 21607 contains only dirty pages, 
and cannot be removed at all from the cache 1602. File 
31608 contains some clean and some dirty pages 1602. The 
clean pages of File 31608 may be removed from the cache 
1602, while the dirty pages must remain. 
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[0210] Selective Write Protection 

[0211] The client streaming software disallows modifica- 
tions to certain application files. This provides several 
benefits, such as preventing vims infections and reducing 
the chance of accidental application corruption. Locally 
installed files are typically not protected in any way other 
than conventional backup. Application file servers may be 
protected against writing by client machines, but are not 
typically protected against viruses running on the server 
itself. Most client file systems allow files to be marked as 
read-only, but it is typically possible to change a file from 
read-only to read-write. The chent application streaming 
software will not allow any data to be written to files that are 
marked as not modifiable. Attempts to mark the file as 
writeable will not be successful. 

[0212] Error Detection and Correction 
[0213] The client streaming software maintains check- 
sums of application code and data and can repair damaged 
or deleted files by retrieving another copy from the appli- 
cation streaming server. Traditional application delivery 
mechanisms do not make any provisions for detecting or 
correcting corrupted application installs. The user typically 
detects a corrupt application, and the only solution is to 
completely reinstall the application. Corrupt application files 
are detected by the invention automatically, and replacement 
code or data are invisibly retrieved by the chent streaming 
software without user intervention. 

[0214] When a block of code or data is requested by the 
client operating system, the client application streaming 
software will compute the checksum of the data block before 
it is returned to the operating system. If this checksum does 
not match that stored in the cache, the client will invalidate 
the cache entry and retrieve a fresh copy of the page from the 

[0215] File Identifiers 

[0216] Applications may be patched or upgraded via a 
change in the root directory for that application. Application 
files that arc not affected by the patch or upgrade need not 
be downloaded again. Most existing file systems do not 
cache files locally. 

[0217] Each file has a unique identifier (number). Files 
that are changed or added in the upgrade are given new 
identifiers never before used for this apphcation. Files that 
are unchanged keep the same number. Directories whose 
contents change are also considered changes. If any file 
changes, this will cause its parent to change, all the way up 
to the root directory. 

[0218] Upgrade Mechanism 

[0219] When the client is informed of an upgrade, it is told 
of the new root directory. It uses this new root directory to 
search for files in the apphcation. When retrieving an old file 
that hasn't changed, it will find the old file identifier, which 
can be used for the existing files in the cache. In this way, 
files that do not change can be reused from the cache without 
downloading them again. For a file that has changed, when 
the file name is parsed, the chent will find a new file number. 
Because this file number did not exist before the upgrade, 
the client will not have this file in the cache, and will stream 
the new file contents when the file is freshly accessed. This 
way it always gets the newest version of files that change. 



[0220] The chent application streaming software can be 
notified of application upgrades by the application streaming 
server. These upgrades can be marked as mandatory, in 
which case the client software will force the application to 
be upgraded. 

[0221] The client will contact the application streaming 
server when it starts the application. At this time, the 
streaming application server can inform the client of any 
upgrades. If the upgrade is mandatory, the client will be 
informed, and it will automatically begin using the upgraded 
application by using the new root directory. 

[0222] Muhicast Technique 

[0223] A broadcast or multicast medium may be used to 
efSciently distribute applications from one application 
streaming server to multiple application streaming clients. 
Traditional networked application delivery mechanisms 
usually involve installing application code and data on a 
central server and having client machines run the apphcation 
from that server. The multicast mechanism allows a single 
server to broadcast or multicast the contents of an apphca- 
tion to many machines simultaneously. The client machines 
will receive the application via the broadcast and save it in 
their local disk cache. The entire application can be distrib- 
uted to a large number of client machines from a single 
server very efficiently. 

[0224] The multicast network is any communication 
mechanism that has broadcast or multicast capabihty. Such 
media mclude television and radio broadcasts and IP mul- 
ticasting on the Internet. Each client that is interested in a 
particular application may listen to the multicast media for 
code and data for that application. The code and data are 
stored in the cache for later use when the application is run. 

[0225] These client techniques can be used to distribute 
data that changes rarely. Application delivery is the most 
appealing use for these techniques, but they could easily be 
adopted to distribute other types of slowly changing code 
and data, such as static databases. 

Load Balancing and Fault Tolerance for Streamed 
Apphcations 

[0226] This section focuses on load balancing (and 
thereby scalability) and hardware fail over. Throughout this 
discussion reference should be made to FIG. 17. Load 
balancing and fault tolerance are addressed in the invention 
by using a smart client and smart server combination. A 
preferred embodiment of the invention that implements 
these features includes three types of servers (described 
below): app servers, SLM servers; and an ASP Web server. 
I'hese are organized as foUows: 

[0227] 1: ASP Web server 1703— This is the Web 
server that the user goes to for subscribing to appli- 
cations, creating accounts etc. Compared to the other 
two types of servers it is characterized by: lowest 
traffic, fewest number of them, & least likely to go 

[0228] 2: SLM Servers 1707— subscription license 
manager servers — These keep track of which user 
has subscribed to what applications under what 
license etc. Compared to the other two types of 
servers it is characterized by: medium traffic, man- 
ageable number, and less likely to go down. 
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[0229] 3: App Servers 1710— These are the servers to 
which the users go to for application pages. Com- 
pared to the other two types of servers it is charac- 
terized by: highest traffic, most number of them, 
most likely to go down either due to hardware failure 
or application re-configuration. 

[0230] Server Lists 

[0231] Clients 1704 subscribe and unsubscribe to appli- 
cations via the ASP Web server 1703. At that point, instead 
of getting a primary and a secondary server that can perform 
the job, the ASP Web server 1703 gives them a non- 
prioritized list of a large number of SLM servers 1706 that 
can do the job. When the application starts to run, each client 
contacts the SLM servers 1707, 1708, 1709 and receive its 
application server list 1705 that can serve the application in 
question and also receive the access tokens that can be used 
to validate themselves with the application servers 1710- 
1715. All access tokens have an expiration time after which 
they need to be renewed. 
[0232] Server Selection 

[0233] Having gotten a server list for each type of server 
1705, 1706, the client 1704 will decide which specific server 
to send its request to. In a basic implementation, a server is 
picked randomly from the list, which will distribute the 
client's load on the servers very close to evenly. An alter- 
native preferred implementation will do as follows: 

[0234] a) Clients will initially pick servers from the 
list randomly, but they will also keep track of the 
overall response time they get from each request; and 

[0235] b) As each client learns about response times 
for each server, it can be more intelligent (rather than 
random) and pick the most responsive server. It is 
believed that the client is better suited at deciding 
which server is most responsive because it can keep 
track of the round trip response time. 

[0236] Client-side Hardware Fail Over 

[0237] The server selection logic provides hardware 

failover in the following manner: 

[0238] a) If a server does not respond, i.e., times out, 
the client 1704 will pick another server from its Kst 
1705, 1706 and re-send the request. Since all the 
ser\'ers in the client's server list 1705, 1706 are 
capable of processing the client's request, there are 
no questions of incompatibility. 

[0239] b) If a SAS cfient 1704 gets a second time out, 
i.e., two servers are down, it re-sends the request to 
multiple servers from its list 1705, 1706 in parallel. 
This approach staggers the timeouts and reduces the 
overall delay in processing a request. 

[0240] c) In case of a massive hardware failure, all 
S6r\'ers in the client's list 1705, 1706 may be down. 
At this point, the client will use the interfaces to 
refresh its server list. This is where the three tiers of 
servers become important: 

[0241] f ) If the client 1704 want to refresh its App 
server list 1705, it will contact an SLM server 
1707, 1709 in its Kst of SLM servers 1706. Again, 
the same random (SLM) server selection order is 



utilized here. Most of the time, this request will be 
successful and the client will get an updated list of 
app servers. 

[0242] 2) If for some reason all of the SLM servers 
1707, 1709 in the client's list 1706 are down, it 
will contact the ASP Web server 1703 to refresh its 
SLM server list 1706. 

[0243] This 3-tiered approach significantly reduces the 
impact of a single point of failure — the ASP Web server 
1703, effectively making it a fail over of a fail over. 
[0244] Server Load Balancing 

[0245] In a preferred embodiment of the invention, a 
server side monitor 1702 keeps track of the overall health 
and response times for each server request. The Monitor 
performs this task for all Application and SLM servers. It 
posts prioritized lists of SLM servers and app servers 1701 
that can serve each of the apps in a database shared by the 
monitor 1702 and all servers. The monitors algorithm for 
prioritizing server lists is dominated by the server's response 
time for each client request. If any servers fail, the monitor 
1702 informs the ASP 1703 and removes it from the server 
hst 1701. Note that the server lists 1705, 1706 that the client 
1704 maintains are subsets of lists the monitor 1702 main- 
tains in a shared database 1701. 

[0246] Since all servers can access the shared database 
1701, they know how to 'cut' a fist of servers to a client. For 
example, the cfient starts to run an SAS application or it 
wants to refresh its app server list: It will contact an SLM 
server and the SLM server wiU access the database 1701 and 
cut a list of servers that are most responsive (from the 
server's prospective). 

[0247] In this scheme, the server monitor 1702 is keeping 
track of what it can track the best: how effectively servers 
are processing cfient requests (server's response time). It 
does not track tfie network propagation delays etc. tfiat can 
significantly contribute to a client's observed response time. 
[0248] ASP Managing Hardware Failovers 

[0249] The foregoing approaches provide an opportunity 
for ASPs to better manage massive scale failures. Specifi- 
cally, when an ASP 1703 realizes that massive numbers of 
servers are down, it can allocate additional resource on a 
temporary basis. The ASP 1703 can update the central 
database 1701 such that clients wfil receive only tfie list that 
the ASP 1703 knows to be up and ninning. This includes any 
temporary resources added to aid the situation. A particular 
advantage of this approach is that ASP 1703 doesn't need 
special actions, e.g., emails or phone support, to route clients 
over to these temporary resources; the transition happens 
automatically. 

[0250] Handling Cfient Crashes and Client Evictions 

[0251] To prevent the same user from running the same 
application from multiple machines, the SLM servers 1707, 
1708, 1709 teack what access tokens have been handed to 
what users. The SAS file system tracks the beginning and 
end of applications. The user's SAS client software asks for 
an access token from the SLM servers 1707, 1708, 1709 at 
the beginning of an application if it already does not have 
one and it releases the access token when the application 
ends. The SLM server makes sure that at a given point only 
one access token has been given to a particular user. In this 
manner, the user can run the appfication from multiple 
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machines, but only from one at a particular time. However, 
if the user's machine crashes before the access token has 
been relinquished or if for some reason the ASP 1703 wants 
to evict a user, the access token granted to the user must be 
made invalid. To perform this, the SLM server gets the list 
of application servers 1705 that have been sent to the client 
1704 for serving the application and sends a message to 
those application servers 1710, 1711, 1713, 1714 to stop 
serving that particular access token. This list is always 
maintained in the database so that every SLM server can find 
out what list is held by the user's machine. The apphcation 
servers before servicing any access token must check with 
this hst to ensure that the access token has not become 
invalid. Once the access token expires, it can be removed 
from this list. 

Server-side Performance Optimization 
[0252] This section describes approaches that can be taken 
to reduce client-side latency (the time between when an 
application page is needed and when it is obtained) and 
improve Application Server scalability (a measure of the 
number of servers required to support a given population of 
clients). The former directly affects the perceived perfor- 
mance of an application by an end user (for application 
features that are not present in the user's cache), while the 
latter directly affects the cost of providing application 
streaming services to a large number of users. 

[0253] Apphcation Server Operation 
[0254] The basic purpose of the Application Server is to 
return Apphcation File Pages over the network as requested 
by a client. The Application Server holds a group of Stream 
Application Sets from which it obtains the Application File 
Pages that match a chent request. The Application Server is 
analogous to a typical network file system (which also 
returns file data), except it is optimized for delivery of 
Application file data, i.e., code or data that belong directly 
to the application, produced by the software provider, as 
opposed to general user file data (document files and other 
content produced by the users themselves). The primary 
differences between the Application Server and a typical 
network file system are: 

[0255] 1. The restriction to handle only Apphcation 
file data allows the Apphcation Server to only ser- 
vice read requests, with writes being disallowed or 
handled on the client itself in a copy-on-write man- 

[0256] 2. Access checks occur at the apphcation 
level, that is a client is given aU-or-none access to 
files for a given software application; 

[0257] 3. The Application Server is designed to oper- 
ate across the Internet, as opposed to typical network 
file systems, which are optimized to run over LANs. 
This brings up additional requirements of handling 
server failures, maximizing network bandwidth and 
minimizing latency, and handhng security; and 

[0258] 4. The Apphcation Server is application- 
aware, unlike typical network file systems, which 
treat all software application files the same as all 
other files. This allows the Application Server to use 
and collect per-application access profile informa- 
tion along with other statistics. 



[0259] To service a chent request, the Application Server 
software component keeps master copies of the full Apph- 
cation Stream Sets on locahy accessible persistent storage. 
In main memory, the Application Server maintains a cache 
of commonly accessed Apphcation File Pages. The primary 
steps taken by the Application Server to service a client 
request are: 

[0260] 1. Receive and decode the client request; 

[0261] 2. Vahdate the client's privilege to access the 
requested data, e.g., b y means of a Kerberos-style 
ticket issued by a trusted security service; 

[0262] 3. Look up the requested data in the main 
memory cache, and failing that, obtain it from the 
master copy on disk while placing it in the cache; and 

[0263] 4. Return the File Pages to the client over the 

[0264] The techniques used to reduce latency and improve 
server scalabihty (the main performance considerations) are 
described below. 

[0265] Server Optimization Features 

[0266] Read-only File System for Apphcation Files— 
Because virtually all application files (code and data) are 
never written to by users, virtuaUy the entire population of 
users have identical copies of the application files. Thus a 
system intending to deliver the application files can distrib- 
ute a single, fixed image across all servers. The read-only file 
system presented by the Apphcation Server represents this 
sharing, and eliminates the complexities of replication man- 
agement, e.g., coherency, that occur with traditional network 
file systems. This simplification enables the Apphcation 
Servers to respond to requests more quickly, enables poten- 
tial caching at intervening nodes or sharing of caches across 
clients in a peer-to-peer fashion, and facilitates fail over, 
since with the read-only file system the Application File 
Pages as identified by the client (by a set of unique numbers) 
will always globally refer to the same content in all cases. 

[0267] Per-page Compression — Overall latency observed 
by the client can be reduced under low-bandwidth condi- 
tions by compressing each Apphcation File Page before 
sending it. Referring to FIG. 18, the benefits of the use of 
compression in the streaming of Application File Pages, is 
illustrated. The client 1801 and server 1802 timehnes are 
shown for a typical transfer of data versus the same data sent 
in a compressed form. The client requests the data from the 
server 1803. The server processes the request 1804 and 
begins sending the requested data. The timelines then 
diverge due to the ability to stream the compressed data 
1805 faster than the uncompressed data 1806. 
[0268] With respect to FIG. 19, the invention's pre- 
compression of Application File Pages process is shown. 
The Builder generates the stream application sets 1901, 
1902 which are then pre-compressed by the Stream Apph- 
cation Set Post-Processor 1903. The Stream Application Set 
Post-Processor 1903 stores the compressed application sets 
in the persistent storage device 1904. Any client requests for 
data are serviced by the Application Server which sends the 
pre-compressed data to the requesting client 1905. The 
reduction in size of the data transmitted over the network 
reduces the time to arrival (though at the cost of some 
processing time on the client to decompress the data). When 
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the bandwidth is low relative to processing power, e.g., 256 
kbps with a Pentium-III-600, this can reduce latency sig- 
nificantly. 

[0269] Page-set Compression — ^When pages are relatively 
small, matching the typical virtual memory page size of 4 
kB, adaptive compression algorithms cannot deliver the 
same compression ratios that they can for larger blocks of 
data, e.g., 32 kB or larger. Referring to FIG. 20, when a 
client 2001 requests multiple Application File Pages at one 
time 2002, the Application Server 2006 can concatenate all 
the requested pages and compress the entire set at once 
2004, thereby further reducing the latency the client will 
experience due to the improved compression ratio. If the 
pages have already been compressed 2003, then the request 
is fulfilled from the cache 2007 where the compressed pages 
are stored. The server 2006 responds to the client's request 
through the transfer of the compressed pages 2005. 

[0270] Post-processing of Stream Application Sets — The 
Application Server may want to perform some post process- 
ing of the raw Stream Application Sets in order to reduce its 
runtime-processing load, thereby improving its perfor- 
mance. One example is to pre-compress all Application File 
Pages contained in the Stream Application Sets, saving a 
great deal of otherwise repetitive processing time. Another 
possibility is to rearrange the format to suit the hardware and 
operating system features, or to reorder the pages to take 
advantage of access locality. 

[0271] Static and Dynamic Profiling— With respect to 
FIG. 21, since the same appHcation code is executed in 
conjunction with a particular Stream Application Set 2103 
each time, there will be a high degree of temporal locality of 
referenced Application File Pages, e.g., when a certain 
feature is invoked, most if not all the same code and data is 
referenced each time to perform the operation. These access 
patterns can be collected into profiles 2108, which can be 
shipped to the client 2106 to guide its prefetching (or to 
guide server-based 2105 prefetching), and they can be used 
to pre-package groups of Application File Pages 2103, 2104 
together and compress them offline as part of a post- 
processing step 2101, 2102, 2103. The benefit of the latter is 
that a high compression ratio can be obtained to reduce 
client latency without the cost of runtime server processing 
load (though only Kmited groups of Application File Pages 
will be available, so requests which don't match the profile 
would get a superset of their request in terms of the 
pre-compressed groups of AppKcation File Pages thai are 
available). 

[0272] Fast Server-Side Client Privilege Checks— Refer- 
ring to FIG. 22, having to track individual user's credentials, 
i.e., which Applications they have privileges to access, can 
Kmit server scalability since ultimately the per-user data 
must be backed by a database, which can add latency to 
servicing of user requests and can become a central bottle- 
neck. Instead, a separate License Server 2205 is used to 
offload per-user operations to grant privileges to access 
application data, and thereby allow the two types of servers 
2205, 2210 to scale independently. The License Server 2205 
provides the client an Access Token (similar to a Kerberos 
ticket) that contains information about what application it 
represents rights for along with an expiration time. This 
simplifies the operations required by the Application Server 
2210 to validate a client's privileges 2212. The AppHcation 



Server 2210 needs only to decrypt the Access Token (or a 
digest of it) via a secret key shared 2209 with the License 
Server 2205 (thus verifying the Token is valid), then check- 
ing the vahdity of its contents, e.g., application identifier, 
and testing the expiration time. Clients 2212 presenting 
Tokens for which all checks pass are granted access. The 
Application Server 2210 needs not track anything about 
individual users or their identities, thus not requiring any 
database operations. To reduce the cost of privilege checks 
further, the Application Server 2210 can keep a list of 
recently used Access Tokens for which the checks passed, 
and if a client passes in a matching Access Token, the server 
need only check the expiration time, with no further decryp- 
tion processing required. 

[0273] Connection Management — Before data is ever 
transferred from a chent to a server, the network connection 
itself takes up one and a half network round trips. This 
latency can adversely impact client performance if it occurs 
for every client request. To avoid this, clients can use a 
protocol such as HTTP 1.1, which uses persistent connec- 
tions, i.e., connections stay open for multiple requests, 
reducing the effective connection overhead. Since the client- 
side file system has no knowledge of the request patterns, it 
will simply keep the connection open as long as possible. 
However, because trafSc from clients may be bursty, the 
Application Server may have more open connections than 
the operating system can support, many of them being 
temporarily idle. To manage this, the Application Server can 
aggressively close connections that have been idle for a 
period of time, thereby achieving a compromise between the 
client's latency needs and the AppHcation Server's resource 
constraints. Traditional network file systems do not manage 
connections in this manner, as LAN latencies are not high 
enough to be of concern. 

[0274] Application Server Memory Usage/Load Balanc- 
ing — File servers are heavily dependent on main memory 
for fast access to file data (orders of magnitude faster than 
disk accesses). Traditional file servers manage their main 
memory as cache of file blocks, keeping the most commonly 
accessed ones. With the Application Server, the problem of 
managing main memory efEciently becomes more compti- 
cated due to there being multiple servers providing a shared 
set of applications. In this case, if each server managed its 
memory independently, and was symmetric with the others, 
then each server would only keep those file blocks most 
common to all clients, across all applications. This would 
cause the most common file blocks to be in the main 
memory of each and every Application server, and since 
each server would have roughly the same contents in 
memory, adding more servers won't improve scalability by 
much, since not much more data wiU be present in memory 
for fast access. For example, if there are application A 
(accessed 50% of the time), application B (accessed 40% of 
the time), and application C (accessed 10% of the time), and 
application A and B together consume more memory cache 
than a single Application Server has, and there are ten 
Application Servers, then none of the Application Servers 
will have many blocks from C in memory, penalizing that 
application, and doubKng the number of servers will 
improve C's performance only minimally. This can be 
improved upon by making the Application Servers asym- 
metric, in that a central mechanism, e.g., system adminis- 
trator, assigns individual Application Servers different 
Application Stream Sets to provide, in accordance with 
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popularity of the various applications. Thus, in the above 
example, of the ten servers, five can be dedicated to provide 
A, four to B, and one to C, (any extra memory available for 
any application) making a much more effective use of the 
entire memory of the system to satisfy the actual needs of 
clients. This can be taken a step further by dynamically (and 
automatically) changing the assignments of the servers to 
match client accesses over time, as groups of users come and 
go during different time periods and as applications are 
added and removed from the system. This can be accom- 
plished by having servers summarize their access patterns, 
send them to a central control server, which then can 
reassign servers as appropriate. 

Conversion of Conventional Applications to Enable 
Streamed Delivery and Execution 
[0275] The Streamed Application Set Builder is a software 
program. It is used to convert locally instaUable applications 
into a data set suitable for streaming over a network. Tlie 
streaming-enabled data set is called the Streamed Applica- 
tion Set (SAS). This section describes the procedure used to 
convert locally installable applications into the SAS. 
[0276] The application conversion procedure into the SAS 
consists of several phases. In the first phase, the Builder 
program monitors the installation process of a local instal- 
lation of the desired application for conversion. The Builder 
monitors any changes to the system and records those 
changes in an intermediate data structure. After the appli- 
cation is installed locally, the Builder enters the second 
phase of the conversion. In the second phase, the Builder 
program invokes the installed appKcation executable and 
obtains sequences of frequently accessed file blocks of this 
application. Both the Builder program and the client soft- 
ware use the sequence data to optimize the performance of 
the streaming process. Once the sequencing information is 
obtained, the Builder enters the final phase of the conver- 
sion. In this phase, the Builder gathers all data obtained from 
the first two phases and processes the data into the Streamed 
Application Set. 

[0277] Detailed descriptions of the three phases of the 
Builder conversion process arc described in the foUowing 
sections. The three phases consist of instaUation monitoring 
(IM), appHcation profiling (AP), and SAS packaging (SP). 
In most cases, the conversion process is general and appli- 
cable to all types of systems. In places where the conversion 
is OS dependent, the discussion is focused on the Microsoft 
Windows environment. Issues on conversion procedure for 
other OS environments are described in later sections. 

[0278] Installation Monitoring (IM) 

[0279] In the first phase of the conversion process, the 
Builder Installation Monitor (IM) component invokes the 
application instaUation program that installs the application 
locally. The IM observes all changes to the local computer 
during the installation. The changes may involve one or 
more of the following: changes to system or environment 
variables; and modifications, addition, or deletion of one or 
more files. Initial system variables, environment variables, 
and files are accounted for by the IM before the installation 
begins to give a more accurate picture of any changes that 
are observed. The IM records all changes to the variables 
and files in a data structure to be sent to the Builder's 
Streamed Application Packaging component. In the follow- 
ing paragraphs, detailed description of the Installation Moni- 
tor is described for Microsoft Windows environment. 



[0280] In Microsoft Windows system, the Installation 
Monitor (IM) component consists of a kernel-mode driver 
subcomponent and a user-mode subcomponent. The kernel- 
mode driver is hooked into the system registry and file 
system function interface calls. The hook into the registry 
function calls allows the IM to monitor system variable 
changes. The hook into the file system function calls enables 
the IM to observe file changes. 

[0281] Installation Monitor Kernel-Mode subcomponent 
(IM-KM) 

[0282] With respect to FIG. 23, the IM-KM subcompo- 
nent monitors two classes of information during an apph- 
cation installation: system registry modifications and file 
modifications. Different techniques are used for each of 
these classes. 

[0283] To monitor system registry modifications 2314, the 
IM-KM component replaces all kernel-mode API calls in the 
System Service Table that write to the system registry with 
new functions defined in the IM-KM subcomponent. When 
an installation program calls one of the API functions to 
write to the registry 2315, the IM-KM function is called 
instead, which logs the modification data 2317 (including 
registry key path, value name and value data) and then 
forwards the call to the actual operating system defined 
function 2318. The modification data is made available to 
the IM-UM subcomponent through a mechanism described 

[0284] To monitor file modifications, a flher driver is 
attached to the file system's driver stack. Each time an 
installation program modifies a file on the system, a function 
is called in the IM-KM subcomponent, which logs the 
modification data (including file path and name) and makes 
it available to the IM-UM using a mechanism described 

[0285] The mechanisms used for monitoring registry 
modifications and file modifications will capture modifica- 
tions made by any of the processes currently active on the 
computer system. While the installation program is running, 
other processes that, for example, operate the desktop and 
service network connections may be running and may also 
modify files or registry data during the installation. This data 
must be removed from the modification data to avoid 
inclusion of modifications that are not part of the apphcation 
installation. The IM-KM uses process monitoring to perform 
this filtering. 

[0286] To do process monitoring, the IM-KM installs a 
process notification callback function that is called each time 
a process is created or destroyed by the operating system. 
Using this callback function, the operating system sends the 
created process ID as well as the process ID of the creator 
(or parent) process. The IM-KM uses this information, along 
with the process ID of the IM-UM, to create a list of all of 
the processes created during the application installation. The 
IM-KM uses the following algorithm to create this list: 

[0287] 1. Before the installation program is launched 
by the IM-UM, the IM-UM passes its own process 
ID to the IM-KM. Since the IM-UM is launching the 
installation appKcation, the IM-UM will be the 
ancestor (parent, grandparent, etc.) of any process 
(with one exception — the Installer Service described 
below) that modifies files or registry data as part of 
the application installation. 
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[0288] 2. When the installation is launched and 
begins the creating processes, the IM-KM process 
monitoring logic is notified by the operating system 
via the process notification callback function. 

[0289] 3. If the creator (parent) process ID sent to the 
process notification callback function is already in 
the process list, the new process is included in the 
list. 

[0290] When an application on the system modifies either 
the registry or files, and the IM-KM monitoring logic 
captures the modification data, but before making it avail- 
able to the IM-UM, it first checks to see if the process that 
modified the registry or file is part of the process list. It is 
only made available to the IM-UM if it is in the process list. 

[0291] It is possible that a process that is not a process 
ancestor of the IM-UM will make changes to the system as 
a proxy for the inslaUation apphcation. Using interprocess 
communication, an installation program may request than an 
Installer Service make changes to the machine. In order for 
the IM-KM to capture changes made by the Installer Ser- 
vice, the process monitoring logic includes a simple rule that 
also includes any registry or file changes that have been 
made by a process with the same name as the Installer 
Service process. On Wmdows 2000, for example, the 
InstaUer Service is called "msi.exe". 

[0292] Installation Monitor User-Mode subcomponent 
(IM-UM) 

[0293] The IM kernel-mode (IM-KM) driver subcompo- 
nent is controUed by the user-mode subcomponent (IM- 
UM). The IM-UM sends messages to the IM-KM to start 
2305 and stop 2309 the monitoring process via standard I/O 
control messages known as lOCTLs. The message that starts 
the IM-KM also passes in the process ID of the IM-UM to 
facilitate process monitoring described in the IM-KM 
description. 

[0294] When the instaUation program 2306 modifies the 
computer system, the IM-KM signals a named kernel event. 
The IM-UM listens for these events during the installation. 
When one of these events is signaled, the IM-UM calls the 
IM-KM using an lOCTL message. In response, the IM-KM 
packages data describing the modification and sends it to the 
IM-UM 2318. 

[0295] The IM-UM sorts this data and removes duplicates. 
Also, it parameterizes all local-system-specific registry 
keys, value names, and values. For example, an apphcation 
will often store paths in the registry that allow it to find 
certain files at run-time. These path specifications must be 
replaced with parameters that can be recognized by the 
client installation software. 

[0296] A user interface is provided for the IM-UM that 
allows an operator of the Builder to browse through the 
changes made to the machine and to edit the modification 
data before the data is packaged into an SAS. 

[0297] Once the instaUation of an application is completed 
2308, the IM-UM forwards data structures representing the 
file and registry modifications to the Streamed Application 
Packager 2312' 



[0298] Monitoring Application Configuration 

[0299] Using the techniques described above for monitor- 
ing file modifications and monitoring registry modifications, 
the builder can also monitor a running application that is 
being configured for a particular working environment. The 
data acquired by the IM-UM can be used to duplicate the 
same configuration on multiple machines, making it unnec- 
essary for each user to configure his/her own apphcation 
instaUation. 

[0300] An example of this is a client server application for 
which the chent will be streamed to the client computer 
system. Common configuration modifications can be cap- 
tured by the IM and packed into the SAS. When the 
application is streamed to the client machine, it is already 
configured to attach to the server and begin operation. 

[0301] Application Profihng (AP) 

[0302] Referring to FIG. 24, in the second phase of the 
conversion process, the Builder's Application Profiler (AP) 
component invokes the apphcation executable program that 
is installed during the first phase of the conversion process. 
Given a particular user input, the executable program file 
blocks are accessed in a particular sequence. The purpose of 
the AP is to capture the sequence data associated with some 
user inputs. This data is useful in several ways. 

[0303] First of all, frequently used file blocks can be 
streamed to the client machine before other less used file 
blocks. A frequently used file block is cached locally on the 
client cache before the user starts using the streamed apph- 
cation for the first time. This has the effect of making the 
streamed apphcation as responsive to the user as the locally 
installed application by hiding any long network latency and 
bandwidth problems. 

[0304] Secondly, the frequently accessed files can be reor- 
dered in the directory to allow faster lookup of the file 
information. This optimization is useful for directories with 
large number of files. When the client machine looks up a 
frequently used file in a directory, it finds this file early in the 
directory search. In an application run with many directory 
queries, the performance gain is significant. 

[0305] Finally, the association of a set of file blocks with 
a particular user input allows the client machine to request 
minimum amount of data needed to respond to that particu- 
lar user command. The profile data association with a user 
command is sent from the server to the cUent machine in the 
AppInstallBlock during the 'preparation' of the client 
machine for streaming. When the user on a client machine 
invokes a particular command, the codes corresponding to 
this command are prefetched from the server. 

[0306] The Apphcation Profiler (AP) is not as tied to the 
system as the Installation Monitor (IM) but there are still 
some OS dependent issues. In the Windows system, the AP 
still has two subcomponents: kernel-mode (AP-KM) sub- 
component and the user-mode (AP-UM) subcomponent. 
The AP-UM invokes the converting apphcation executable. 
Then AP-UM starts the AP-KM 2403, 2413 to track the 
sequences of file block accesses by the application 2414. 
Finally when the application exits after the pre-specified 
amount of sequence data is gathered, the AP-UM retrieves 
the data from AP-KM 2406, 2417 and forwards the data to 
the Streamed Application Packager 2411. 
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[0307] Streamed Application Set Packaging (SP) 

[0308] With respect to FIG. 25, in the final phase of the 
conversion process, the Builder's Streamed Application Set 
Packager (SP) component processes the data structure from 
IM and AP to create a data set suitable for streaming over the 
network. This converted data set is called the Streamed 
Application Set 2520 and is suitable for uploading to the 
Streamed Application Servers for subsequent downloading 
by the stream client. FIG. 23 shows the control flow of the 
SP module. 

[0309] Each file included in a Streamed Apphcation Set 
2520 is assigned a file number that identifies it within the 
SAS. 

[0310] The Streamed Apphcation Set 2520 consists of the 
three sets of data from the Streamed Application Server's 
perspective. The three types of data are the Concatenation 
Application File (CAF) 2519, 2515, the Size Offset File 
Table (SOFT)2518, 2514, 2507, and the Root Versioning 
Table (RVT) 2518, 2514. 

[0311] The CAF 2519, 2515 consists of all the files and 
directories needed to stream to the client. The CAF can be 
further divided into two subsets: initialization data set and 
the runtime data set. 

[0312] The initiahzation data set is the first set of data to 
be streamed from the server to the client. This data set 
contains the information captured by IM and AP needed by 
the client to prepare the client machine for streaming this 
particular application. This initialization data set is also 
called the AppInstallBlock (AIB) 2516, 2512. hi addition to 
the data captured by the IM and AP modules, the SP is also 
responsible for merging any new dynamic profile data 
gathered from the client and the server. This data is merged 
into the existing AppInstaUBlock to optimize subsequent 
streaming of the apphcation 2506. With the list of files 
obtained by the TM during application installation, the SP 
module separates the list of files into regular streamed files 
and the spoof files. The spoof files consists of those files not 
instaUed into standard apphcation directory. This includes 
files installed into system directories and user specific direc- 
tories. The detailed format description of the AppInstaU- 
Block is described later. 

[0313] The second part of the CAF consists of the runtime 
data set. This is the rest of the data that is streamed to the 
client once the client machine is initialized for this particular 
application. The runtime data consists of all the regular 
application files and the directories containing information 
about those application files. Detailed format description of 
the runtime data in the CAF section is described below. The 
SP appends every file recorded by IM into the CAF and 
generates all directories. Each directory contains list of file 
name, file number, and the metadata associated with the files 
in that particular directory 2517, 2513. 

[0314] The SP is also responsible for generating the SOFT 
file 2518, 2514, 2507. This is a tabic used to index into the 
CAF for determining the start and the end of a file. The 
server uses this information to quickly access the proper file 
within the directory for serving the proper file blocks to the 

[0315] FinaUy, the SP creates the RVT file 2518, 2514. The 
Root Versioning Table contains a list of root file number and 
version number. This information is used to track minor 
application patches and upgrades. Each entry in the RVT 
corresponds to one patch level of the application with a 



corresponding new root directory. The SP generates new 
parent directories when any single file in that subdirectory 
tree is changed from the patched upgrade. The RVT is 
uploaded to the server and requested by the client at appro- 
priate time for the most updated version of the apphcation by 
a simple comparison of the client's Streamed Apphcation 
root file number with the RVT table located on the server 
once the client is granted access authorization to retrieve the 

[0316] With respect to FIGS. 26fl and 26b, the internal 
representation of a simple SAS before and after a new file is 
added to a new version of an apphcation is shown. The 
original CAF 2601 has the new files 2607 appended to it 

2604 by the SR The SOFT 2602 is correspondingly updated 

2605 with the appropriate table entries 2608 to index the 
new files 2607 the CAF 2604. Finally, the RVT 2603 is 
updated 2606 to reflect the new version 2609. 

[0317] Data Flow Description 

[0318] The following list describes the data that is passed 
from one component to another. The numbers corresponds to 
the numbering in the Data Flow diagram of FIG. 27. 
[0319] InstaU Monitor 

[0320] f . The full pathname of the installer program 

is queried from the user by the Builder program and 

is sent to the Install Monitor. 
[0321] 2. The InstaU Monitor (IM) user-mode sends 

a read request to the OS to spawn a new process for 

installing the application on the local machine. 

[0322] 3. The OS loads the application installer pro- 
gram into memory and runs the application installer 
program. OS returns the process ID to the IM. 

[0323] 4. The apphcation program is started by the 
IM-UM. 

[0324] 5. The application instaUer program sends 
read request to the OS to read the content of the CD. 

[0325] 6. The CD media data files are read from the 
CD. 

[0326] 7. The files arc written to the appropriate 
location on the local hard-drive. 

[0327] 8. IM kernel-mode captures all file read/write 
requests and all registry read/write requests by the 
application installer program. 

[0328] 9. IM user-mode program starts the IM ker- 
nel-mode program and sends the request to start 
capturing aU relevant file and registry data. 

[0329] f 0. IM kernel-mode program sends the list of 
all file modifications, additions, and deletions; and 
ah registry modifications, additions, and deletions to 
the IM user-mode program. 

[0330] fl. IM informs the SAS BuUder UI that the 
installation monitoring has completed and displays 
the file and registry data in a graphical user interface. 

[0331] Application Profiler 

[0332] 12. Builder UI invokes Apphcation Profiting 
(AP) user-mode program by querying the user for the 
list of application executable names to be profiled. 
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The AP user-mode also queries the user for division 
of file blocks into sections corresponding to the 
commands invoked by the user of the apphcation 
being profiled. 

[0333] 13. Apphcation Profiler user-mode invokes 
each application executable in succession by spawn- 
ing each program in a new process. The OS loads the 
application executable into memory, runs the appli- 
cation executable, and returns the process ID to the 
Application Profiler. 

[0334] 14. During execution, the OS on behalf of the 
application, sends the request to the hard-drive con- 
troller to read the appropriate file blocks into 
memory as needed by the application. 

[0335] 15. The hard-drive controller returns all file 
blocks requested by the OS. 

[0336] 16. Every file access to load the apphcation 
file blocks into memory is monitored by the Appli- 
cation Profiler (AP) kernel-mode program. 

[0337] 17. The AP user-mode program informs the 
AP kernel-mode program to start monitoring rel- 
evant file accesses. 

[0338] 18. Application Profiler kernel-mode returns 
the file access sequence and frequency information 
to the user-mode program. 

[0339] 19. Application Profiler returns the processed 
profile information. This has two sections. The first 
section is used to identify the frequency of files 
accessed. The second section is used to list the file 
blocks for prefetch to the client. The file blocks can 
be further categorized into subsections according to 
the commands invoked by the user of the applica- 

[0340] SAS Packager 

[0341] 20. The Streamed Application Packager 
receives files and registry changes from the Builder 
UI. It also receives the file access frequency and a list 
of file blocks from the Profiler. File numbers are 
assigned to each file. 

[0342] 21 . The Streamed Apphcation Packager reads 
all the file data from the hard-drive that are copied 
there by the application installer. 

[0343] 22. The Streamed Application Packager also 
reads the previous version of Streamed Apphcation 
Set for support of minor patch upgrades. 

[0344] 23. Finally, the new Streamed Application Set 
data is stored back to non-volatile storage. 

[0345] 24. For new profile data gathered after the 
SAS has been created, the packager is invoked to 
update the AppInstallBlock in the SAS with the new 
profile information. 

[0346] Mapping of Data Flow to Streamed Application Set 
(SAS) 

[0347] Step 7: Data gathered from this step consist of 
the registry and file modification, addition, and dele- 
tion. The data are mapped to the AppInstallBlock' s 
File Section, Add Registry Section, and Remove 
Registry Section. 



[0348] Step 8 & 19: File data are copied to the local 
hard-drive then concatenated into part of the CAF 
contents. Part of the data is identified as spoof or 
copied flies and the file names and/or contents are 
added to the AppInstallBlock. 

[0349] Step 15 & 21 : Part of the data gathered by the 
Profiler or gathered dynamically by the client is used 
in the AppInstallBlock as a prefetch hint to the client. 
Another part of the data is used to generate a more 
efScient SAS Directory content by ordering the files 
according the usage frequency. 

[0350] Step 20: If the installation program was an 
upgrade, SAS Packager needs previous version of 
the Streamed Apphcation Set data. Appropriate data 
from the previous version are combined with the new 
data to form the new Streamed Application Set. 

[0351] Format of Streamed Application Set 

[0352] Referring to FIG. 28, the format of the Streamed 
Application Set consists of three sections: Root Version 
Table (RVT) 2802, Size Offset File Table (SOFT) 2803, and 
Concatenation Apphcation File (CAF) 2801. The RVT sec- 
tion 2802 lists all versions of the root file numbers available 
in a Streamed Application Set. The SOFT 2803 section 
consists of the pointers into the CAF 2801 section for every 
file in the CAF 2801. The CAF section 2801 contains the 
concatenation of ah the files associated with the streamed 
apphcation. The CAF section 2801 is made up of regular 
application files, SAS directory files 2805, AppInstallBlock 
2804, and icon files. See below for detailed information on 
the content of the SAS file. 

[0353] OS Dependent Format 

[0354] The format of the Streamed Application Set is 
designed to be as portable as possible across aU OS plat- 
forms. At the highest level, the format of CAF, SOFT, and 
RVT that make up the format of the Streamed Application 
Set are completely portable across any OS platforms. One 
piece of data structure that is OS dependent is located in the 
initiahzation data set called AppInstallBlock in the CAF. 
This data is dependent on the type of OS due to the 
differences in low-level system differences among different 
OS. For example, Microsoft Windows contains system envi- 
ronment variables called the Registry. The Registry has a 
particular tree format not found in other operating systems 
like UNIX or MacOS. 

[0355] Another OS dependent piece of data is located in 
the SAS directory files in the CAF. The directory contains 
file metadata information specific to Windows files. For 
example on the UNIX platform, there does not exist a hidden 
flag. This platform speciflc information needs to be trans- 
mitted to the client to fool the streamed application into 
believing that the application data is located natively on the 
client machine with all the associated flle metadata intact. If 
SAS is to be used to support streaming of UNIX or MacOS 
applications, file metadata specific to those systems will 
need to be recorded in the SAS directory. 

[0356] Lastly, the format of the file names itself is OS 
dependent. Applications running on the Windows environ- 
ment inherit the old MSDOS 8.3 file name format. To 
support this properly, the format of the SAS Directory file in 
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CAF requires an additional 8.3 field to store this informa- 
tion. This field is not needed in other operating systems like 
UNIX or MacOS. 

[0357] Device Driver Versus File System Paradigm 
[0358] Referring to FIGS. 29 and 30, the SAS dient 
Prototype is implemented using the 'device driver' para- 
digm. One of the advantages of the device driver approach 
is that the caching of the sector blocks is simpler. In the 
device driver approach, the client cache manager 2902 only 
needs to track sector numbers in its cache 2903. In com- 
parison with the 'file system' paradigm, more complex data 
structure are required by the client cache manager 3002 to 
track a subset of a file that is cached 3003 on a client 
machine. This makes the device driver paradigm easier to 
implement. 

[0359] On the other hand, there are many drawbacks to the 
device driver paradigm. On the Windows system, the device 
driver approach has a problem supporting large numbers of 
applications. This is due to the phantom hmitation on the 
number of assignable drive letters available in a Windows 
system (26 letters); and the fact that each apphcation needs 
to be located on its own device. Note that having multiple 
applications on a device is possible, but then the server 
needs to maintain an exponential number of devices that 
support all possible combinations of applications. This is too 
costly to maintain on the server. 

[0360] Another problem with the device driver approach is 
that the device driver operates at the disk sector level. This 
is a much lower level than operating at the file level in the 
file system approach. The device driver does not know 
anything about files. Thus, the device driver cannot easily 
interact with the file level issues. For example, spoofing files 
and interacting with the OS file cache is nearly impossible 
with the device driver approach. Both spoofing files and 
interacting with the OS buffer cache are needed to get higher 
performance. In addition, operating at the file system level 
lends to optimizing the file system to better suit this 
approach of mnning applications. For instance, typical file 
systems do logging and make multiple disk sector requests 
at a time. These are not needed in this approach and are 
actually detrimental to the performance. When operating at 
the device driver level, not much can be done about that. 
Also, operating at the file system level helps in optimizing 
the protocol between the client and the server 

[0361] Implementation in the Prototype 
[0362] The prototype has been implemented and tested 
successfully on the Windows and Linux distributed system. 
The prototype is implemented using the device driver para- 
digm as described above. The exact procedure for streaming 
application data is described next. 

[0363] First of all, the prototype server is started on either 
the Windows-based or Linux-based system. The server 
creates a large local file mimicking large local disk images. 
Once the disk images are prepared, it hstens to TCP/IP ports 
for any disk sector read or write requests. 

[0364] Implementation of SAS Builder 

[0365] The SAS Builder has been implemented on the 
Windows-based platform. A pretiminary Streamed Applica- 
tion Set file has been created for real-world applications like 
Adobe Photoshop. A simple extractor program has been 



developed to extract the SAS data on a pristine machine 
without the application installed locally. Once the extractor 
program is run on the SAS, the apphcation runs as if it was 
installed locally on that machine. This process verifies the 
correctness of the SAS Building process. 

Format of Streamed Application Set (SAS) 
[0366] Functionality 

[0367] The streamed application set (SAS), illustrated in 
FIG. 28, is a data set associated with an application suitable 
for streaming over the network. The SAS is generated by the 
SAS Builder program. The program converts locally install- 
able apphcations into the SAS. This section describes the 
format of the SAS. 

[0368] Note: Fields greater than a single byte are stored in 
little-endian format. The Stream Application Set (SAS) file 
size is limited to 2" 64 bytes. The files in the CAF section 
are laid out in the same order as its corresponding entries in 
the SOFT table. 

[0369] Data Type Definitions 

[0370] The format of the SAS consists of four sections: 
header. Root Version Table (RVT), Size Offset File Table 
(SOFF), and Concatenation Apphcation File (CAF) sec- 

[0371] 1. Header Section 

[0372] MagicNumber [4 bytes]: Magic number iden- 
tifying the file content with the SAS. 

[0373] ESSVersion [4 bytes]: Version number of the 
SAS file format. 

[0374] AppID [16 bytes]: Aunique application ID for 
this application. This field must match the AppID 
located in the AppInstallBlock. Window Guidgen 
API is used to create this identifier. 

[0375] Flags [4 bytes]: Flags pertaining to SAS. 

[0376] Reserved [32 bytes]: Reserved spaces for 

[0377] RVToffset [8 bytes]: Byte offset into the start 
of the RVT section. 

[0378] RVTsize [8 bytes]: Byte size of the RVT 



[0379] SOFToffset [8 bytes]: Byte offset into the start 
of the SOFT section. 

[0380] SOFTsize [8 bytes]: Byte size of the SOFT 



[0381] CAFoffset [8 bytes]: Byte offset into the start 
of the CAF section. 

[0382] CAFsize [8 bytes]: Byte size of the CAF 

[0383] VendorNamelsAnsi [1 byte]: 0 if the vendor 
name is in Unicode format. 1 if the vendor name is 
in ANSI format. 

[0384] VendorNameLength [4 bytes]: Byte length of 
the vendor name. 
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[0385] VendorName [X bytes]: Name of the software 

vendor who created this application, e.g., 

"Microsoft". Null-terminated. 
[0386] AppBaseNamelsAnsi [1 byte]: 0 if the vendor 

name is in Unicode format, i if the vendor name is 

in ANSI format. 
[0387] AppBaseNameLength [4 bytes]: Byte length 

of the application base name. 
[0388] AppBaseName [X bytes]: Base name of the 

application, e.g., "Word 2000". Null-terminated. 

[0389] MessagelsAnsi [f byte]: 0 if the vendor name 
is in Unicode format. 1 if the vendor name is in ANSI 
format. 

[0390] MessageLength [4 bytes]: Byte length of the 
message text. 

[0391] Message [X bytes]: Message text. NuU-tcrmi- 

[0392] 2. Root Version Table (RVT) Section 

[0393] The Root version entries are ordered in a decreas- 
ing value according to their file numbers. The Builder 
generates unique file numbers within each SAvS in a mono- 
tonically increasing value. So larger root file numbers imply 
later versions of the same application. The latest root version 
is located at the top of the section to allow the SAS Server 
easy access to the data associated with the latest root 

[0394] NumberEntries [4 bytes]: Number of patch 
versions contained in this SAS. The number indi- 
cates the number of entries in the Root Version Table 
(RVT). 

[0395] Root Version structure: (variable number of 

[0396] VersionNumber [4 bytes]: Version number of 

the root directory. 
[0397] FileNumber [4 bytes]: File number of the root 

directory. 

[0398] VersionNamelsAnsi [1 byte]: 0 if the vendor 
name is in Unicode format, f if the vendor name is 
in ANSI format. 

[0399] VersionNameLength [4 bytes]: Byte length of 
the version name 

[0400] VersionName [X bytes]: AppKcation version 
name, e.g., "SP f". 

[0401] Metadata [32 bytes]: See SAS FS Directory 
for format of the metadata. 

[0402] 3. Size Offset File Table (SOFT) Section 
[0403] The SOFT table contains information to locate 
specific files in the CAP section. The entries are ordered 
according to the file number starting from 0 to NumberFiles- 
1. The start of the SOFT table is aligned to eight-byte 
boundaries for faster access. 

[0404] SOFT entry structure: (variable number of entries) 

[0405] Offset [8 bytes]: Byte offset into CAF of the 
start of this file. 

[0406] Size [8 bytes]: Byte size of this file. The file is 
located from address Offset to Offset-nSize. 



[0407] 4. Concatenation Application File (CAF) Section 
[0408] CAF is a concatenation of all file or directory data 
into a single data structure. Each piece of data can be a 
regular file, an AppInstallBlock, an SAS FS directory file, or 
an icon file. 

[0409] a. Regular Files 

[0410] FileData [X bytes]: Content of a regular file 

[0411] b. AppInstallBlock (See AppInstaUBlock section 
for detailed format) A simpKfied description of the AppIn- 
stallBlock is hsted here. The exact detail of the individual 
fields in the AppInstallBlock are described later. 

[0412] Header section [X bytes]: Header for AppIn- 
stallBlock containing information to identify this 
AppInstallBlock. 

[0413] Files section [X bytes]: Section containing file 
to be copied or spoofed. 

[0414] AddVariable section [X bytes]: Section con- 
taining system variables to be added. 

[0415] Remove Variable section [X bytes]: Section 
containing system variables to be removed. 

[0416] Prefetch section [X bytes]: Section containing 
pointers to file blocks to be prefetched to the client. 

[0417] Profile section [X bytes]: Section containing 
profile data. 

[0418] Comment section [X bytes]: Section contain- 
ing comments about AppInstallBlock. 

[0419] Code section [X bytes]: Section containing 
application-specific code needed to prepare local 
machine for streaming this application 

[0420] LicenseAgreement section [X bytes]: Section 
containing licensing agreement message. 
[0421] c. SAS Directory 

[0422] An SAS Directory contains information about the 
subdirectories and files located within this directory. This 
information is used to store metadata information related to 
the files associated with the streamed application. This data 
is used to fool the apphcation into thinking that it is running 
locally on a machine when most of the data is resided 
elsewhere. 

[0423] The SAS directory contains information about files 
in its directory. The information includes file number, 
names, and metadata associated with the files. 

[0424] MagicNumber [4 bvtes]: Magic number for 
SAS directory file. 

[0425] ParentFilelD [16+4 bytes]: AppID-^FileNum- 

ber of the parent directory. AppID is set to 0 if the 

directory is the root. 
[0426] SelfFilelD [16+4 bytes]: AppID+FileNumber 

of this directory. 
[0427] NumFiles [4 bytes]: Number of files in the 

directory. 
[0428] Variable-Sized File Entry: 

[0429] UscdFlag [f byte]: 1 for used, 0 for unused. 
[0430] ShortLen [f byte]: Length of short file name. 
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[0431] LongLen [2 byte]: Length of long file name. 
[0432] NameHash [4 bytes]: Hash value of the short 
file name for quick lookup without comparing whole 

[0433] ShortName [24 bytes]: 8.3 short file name in 
Unicode. Not null-terminated. 

[0434] FilelD [i6+4 bytes]: AppID+FileNumber of 
each file in this directory. 

[0435] Metadata [32 bytes]: The metadata consists of 
file byte size (8 bytes), file creation time (8 bytes), 
file modified time (8 bytes), attribute flags (4 bytes), 
SAS flags (4 bytes). The bits of the attribute flags 
have the foUowing meaning: 

[0436] Bit 0: Read-only— Set if file is read-only 
[0437] Bit 1: Hidden— Set if file is hidden from 

[0438] Bit 2: Directory— Set if the file is an SAS 
Directory 

[0439] Bit 3: Archive— Set if the file is an archive 
[0440] Bit 4: Normal— Set if the file is normal 
[0441] Bit 5 : System— Set if the file is a system file 
[0442] Bit 6: Temporary — Set if the file is tempo- 

[0443] The bits of the SAS flags have the following 
meaning: 

[0444] Bit 0: ForceUpgrade— Used only on root 
file. Set if client is forced to upgrade to this 
particular version if the current root version on the 
client is older. 

[0445] Bit 1: RequireAccessToken— Set if file 
require access token before client can read it. 

[0446] Bit 2: Read-only— Set if the file is rcad- 

[0447] LongName [X bytes]: Long filename in Uni- 
code format with null-termination character. 

[0448] d. Icon files 

[0449] IconFileData [X bytes]: Content of an icon 
file. 

Format of AppInstaflBlock 
[0450] FunctionaKty 

[0451] With respect to FIGS. 31fl-31A, the AppInstafl- 
Block is a block of code and data associated with a particular 
application. This AppInstallBlock contains the information 
needed to by the SAS client to initialize the cKent machine 
before the streamed application is used for the first time. It 
also contains optional profiling data for increasing the 
runtime performance of that streamed application. 

[0452] The AppInstallBlock is created offline by the SAS 
Builder program. First of all, the Builder monitors the 
installation process of a local version of the application 
instaflation program and records changes to the system. This 
includes any environment variables added or removed from 
the system 3103, and any files added or modified in the 



system directories 3102. Files added to the apphcation 
specific directory are not recorded in the AppInstallBlock to 
reduce the amount of time needed to send the AppInstafl- 
Block to the SAS client. Secondly, the Builder profiles the 
application to obtain the list of critical pages needed to run 
the apphcation initially and an initial page reference 
sequence of the pages accessed during a sample run of the 
application. The AppInstaflBlock contains an optional apph- 
cation-specific initialization code 3107. This code is needed 
when the default initialization procedure is insufficient to 
setup the local machine environment for that particular 
application. 

[0453] The AppInstaflBlock and the runtime data are 
packaged into the SAS by the Builder and then uploaded to 
the application server. After the SAS client is subscribed to 
an application and before the application is nin for the first 
time, the AppInstallBlock is sent by the server to the client. 
The SAS client invokes the default initialization procedure 
and the optional application-specific initialization code 
3107. Together, the defauk and the application-specific 
initiahzation procedure process the data in the AppInstafl- 
Block to make the machine ready for streaming that par- 
ticular application. 
[0454] Data Type Definitions 

[0455] The AppInstallBlock is divided into the following 
sections: header section 3101, variable section 3103, file 
section 3102, profile section 3105, prefetch section 3104, 
comment section 3106, and code section 3107. The header 
section 3101 contains general information about the AppIn- 
stallBlock. The information includes the total byte size and 
an index table containing size and offset into other sections. 
In a Windows version, the variable section consists of two 
registry tree structures to specify the registry entries added 
or removed from the OS environment. The file section 3102 
is a tree structure consisting of the files copied to C drive 
during the application installation. The profile section 3105 
contains the initial set of block reference sequences during 
Builder profiling of the application. The prefetch section 
3104 consists of a subset of profiled blocks used by the 
Builder as a hint to the SAS client to prefetch initially. The 
comment section 3106 is used to inform the SAS chent user 
of any relevant information about the application installa- 
tion. Finally, the code section 3107 contains an optional 
program tailored for any application-specific installation not 
covered by the default streamed apphcation mstaflation 
procedure. In Windows version, the code section contains a 
Windows DLL. The following is a detailed description of 
each fields of the AppInstallBlock. 

[0456] Note: Little endian format is used for all the fields 
spanning more than 1 byte. Also, BlockNumber specifies 
blocks of 4K byte size. 
[0457] i. Header Section 

[0458] The header section 3103 contains the basic infor- 
mation about this AppInstaflBlock. This includes the ver- 
sioning information, apphcation identification, and index 
into other sections of the file. 
[0459] Core Header Structure 

[0460] AibVersion [4 bytes]: Magic number or 
appInstallBlock version number (which identifies the 
version of the appInstallBlock structure rather than 
the contents). 



Appellant's Reply Brief EFS filed 05/30/2008 



Page 460 of 1275 



Application No. 09/912636 



us 2002/0083183 Al 



23 



Jun. 27, 2002 



[0461] Appid [16 bytes]: this is an application iden- 
tifier unique for each application. On Windows, this 
identifier is the GUID generated from the 'guidgen' 
program. Appld for Word on Win98 will be different 
from Word on WinNT if it turns out that Word 
binaries are different between NT and 98. 

[0462] VersionNo [4 bytes]: Version number. This 
allows us to mform the client that the applnstall- 
Block has changed for a particular appld. This is 
useful for changes to the AppInstallBlock due to 
minor patch upgrades in the apphcation. 

[0463] CHentOSBitMap [4 bytes]: Client OS sup- 
ported bitmap or ID: for Win2K, Win98, WinNT 
(and generally for other and multiple OSs). 

[0464] CHentOSServicePack [4 bytes]: For optional 
storage of the service pack level of the OS for which 
this appInstallBlock has been created. Note that 
when this field is set, the multiple OS bits in the 
above field CHentOSBitMap are not used. 

[0465] Flags [4 bytes]: Flags pertaining to Appln- 
staUBlock 

[0466] Bit 0: Reboot— If set, the SAS client needs 
to reboot the machine after installing the AppIn- 
stallBlock on the client machine. 

[0467] Bit 1 : U nicode— If set, the string characters 
are 2 bytes wide instead of 1 byte. 

[0468] HeaderSize [2 bytes]: Total size in bytes of the 
header section. 

[0469] Reserved [32 bytes]: Reserved spaces for 

[0470] NumberOfSections [1 byte]: Number of sec- 
tions in the index table. 

[0471] This determines the number of entries in the index 
table structure described below: 

[0472] Index Table Structure: (Variable Number of 
Entries) 

[0473] SectionType [1 bytes]: The type of data 
described in section. 0=fil6 section, l=variable sec- 
tion, 2=prefetch section, 3=profile section, 4=com- 

[0474] SectionOffset [4 bytes]: The offset from the 
beginning of the file indicates the beginning of 



[0475] SectionSize [4 bytes]: The size in bytes of 



[0476] Variable Structure 

[0477] ApplicationNamelsAnsi [1 byte]: 1 if ansi, 0 
if Unicode. 

[0478] ApplicationNameLength [4 bytes]: Byte size 
of the application name 

[0479] ApplicationName [X bytes]: NuU terminating 
name of the application 



[0480] 2. File Section 

[0481] The file section 3102 contains a subset of the list of 
files needed by the apphcation to run properly. This section 
does not enumerate files located in the standard apphcation 
program directory. It consists of information about files 
copied into an 'unusual' directory during the installation of 
an application. If the file content is small (typically less than 
1 MB), the file is copied to the client machine. Otherwise, 
the file is relocated to the standard program directory 
suitable for streaming. The file section data is a Kst of trees 
stored in a contiguous sequence of address spaces according 
to the pre-order traversal of the trees. A node in the tree can 
correspond to one or more levels of directories. A parent- 
child node pair is combined into a single node if the parent 
node has only a single child. Parsing the tree from the root 
of the tree to a leaf node results in a fully legal Windows 
pathname including the drive letter. Each entry of the node 
in the tree consists of the following structure: 

[0482] Directory Structure: (Variable Number of Entries) 
[0483] Flags [4 byte]: Bit 0 is set if this entry is a 
directory 

[0484] NumberOfChildren [2 bytes]: Number of 
nodes in this directory 

[0485] DirectoryNameLength [4 bytes]: Length of 
the directory name 

[0486] DirecloryName [X bytes]: Null terminating 
directory name 

[0487] Leaf Structure: (Variable Number of Entries) 

[0488] Flags [4 byte]: Bit 1 is set to 1 if this entry is 

a spoof or copied file name 
[0489] File Version [8 bytes]: Version of the file Get- 
File VersionInfo( ) if the file is Win32 file image. 
Need variable file version size returned by GetFile- 
VersionInfoSize( ). Otherwise use file size or file 
modified time to compare which file is the later 

[0490] FileNameLength [4 bytes]: Bvte size of the 
file name 

[0491] FileName [X bytes]: Null terminating file 

[0492] DataLength [4 bytes]: Byte size of the data. If 
spoof file, then data is the string of the spoof direc- 
tory. If copied file, then data is the content of the file 

[0493] Data [X bytes]: Either the spoof file name or 
the content of the copied file 

[0494] 3. Add Variable and Remove Variable Sections 
[0495] The add and remove variable sections 3103 contain 
the system variable changes needed to run the application. In 
a Windows system, each section consists of several number 
of registry subtrees. Each tree is stored in a contiguous 
sequence of address spaces according to the pre-order tra- 
versal of the tree. A node in the tree can correspond to one 
or more levels of directory in the registry. A parent-child 
node pair is combined into a single node if the parent node 
has only a single child. Parsing the tree from the root of the 
tree to a leaf node results in a fully legal key name. The order 
of the trees is shown here. 
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[0496] a. Registry Subsection: 

[0497] 1. "HKCR": HKEY_CLASSES_ROOT 
[0498] 2. "HKCU": HKEY_CURRENT_USER 
[0499] 3. "HKLM": HKEY_LOCAL_MACHINE 
[0500] 4. "HKUS": HKEY_USERS 
[0501] 5. "HKCC": HKEY_CURRENT_CONFIG 

[0502] Tree Structure: (5 entries) 

[0503] ExistFlag [1 byte]: Set to 1 if this tree exist, 0 
otherwise. 

[0504] Key or Value Structure entries [X bytes]: 
Serialization of the tree into variable number key or 
value structures described below. 

[0505] Key Structure: (Variable Number of Entries) 

[0506] KeyFlag [1 byte]: Set to 1 if this entry is a key 
or 0 if it's a value structure 

[0507] NumberOfSubchild [4 bytes]: Number of sub- 
keys and values in this key directory 

[0508] KeyNanieLength [4 bytes]: Byte size of the 
[0509] KeyName [X bytes]: Null terminating key 

[0510] Value Structure: (Variable Number of Entries) 

[0511] KeyFlag [f byte]: Set to 1 if this entry is a key 
or 0 if it's a value structure 

[0512] ValueType [4 byte]: Type of values from the 
Win32 API function RegQueryValueEx( ): REG_SZ, 
REG_BINARY, REG_DWORD, REG_LINK, 
REG_NONE, etc . . . 

[0513] ValueNameLength [4 bytes]: Byte size of the 

[0514] ValueName [X bytes]: Null terminating value 

[0515] ValueDataLength [4 bytes]: Byte size of the 
value data 

[0516] ValueData [X bytes]: Value of the Data 

[0517] In addition to registry changes, an installation in a 
Windows system may involve changes to the ini files. The 
following structure is used to communicate the ini file 
changes needed to be done on the SAS client machine. The 
ini entries are appended to the end of the variable section 
after the five registry trees are enumerated. 

[0518] b. INI Subsection 

[0519] NumFiles [4 bytes]: Number of INI files 
modified. 

[0520] File Structure: (Variable Number of Entries) 

[0521] FileNameLength [4 bytes]: Byte length of the 
file name 

[0522] FileName [X bytes]: Name of the INI file 

[0523] NumSection [4 bytes]: Number of sections 
with the changes 



[0524] Section Structure: (Variable Number of Entries) 

[0525] SectionNameLength [4 bytes]: Byte length of 
the section name 

[0526] SectionName [X bytes]: Section name of an 
INI file 

[0527] Num Values [4 bytes]: Number of values in 
this section 

[0528] Value Structure: (Variable Number of Entries) 

[0529] ValueLength [4 bytes]: Byte length of the 
value data 

[0530] ValueData [X bytes]: Content of the value 
[0531] 4. Prefetch Section 

[0532] The prefetch section 3104 contains a hst of file 
blocks. The Builder profiler determines the set of file blocks 
critical for the initial nin of the appKcation. This data 
includes the code to start and terminate the application. It 
includes the file blocks containing frequently used com- 
mands. For example, opening and saving of documents are 
frequently used commands and should be prefetched if 
possible. Another type of block to include in the prefetch 
section are the blocks associated with frequently accessed 
directories and file metadata in this directory. The prefetch 
section is divided into two subsections. One part contains the 
critical blocks that are used during startup of the streamed 
application. The second part consists of the blocks accessed 
for common user operations like opening and saving of 
document. The format of the data is described below: 
[0533] a. Critical Block Subsection: 

[0534] NumCriticalBlocks [4 bytes]: Number of 
critical blocks. 

[0535] Block Structure: (Variable Number of Entries) 

[0536] FileNumber [4 bytes]: File Number of the file 
containing the block to prefetch 

[0537] BlockNumber [4 bytes]: Block Number of the 
file block to prefetch 

[0538] b. Common Block Subsection: 

[0539] NumCommonBlocks [4 bytes]: Number of 
critical blocks. 

[0540] Block Structure: (Variable Number of Entries) 

[0541] FileNumber [4 bytes]: File Number of the file 
containing the block to prefetch 

[0542] BlockNumber [4 bytes]: Block Number of the 
file block to prefetch 

[0543] 5. Profile Section 

[0544] The profile section 3105 consists of a reference 
sequence of file blocks accessed by the application at 
runtime. Conceptually, the profile data is a two dimensional 
matrix. Each entry [row, column] of the matrix is the 
frequency, a block row is followed by a block column. In 
any realistic applications of fair size, this matrix is very large 
and sparse. The proper data structure must be selected to 
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store this sparse matrix elEciently in required storage space 
and minimize the overhead in accessing this data structure 

[0545] The section is constructed from two basic struc- 
tures: row and column structures. Each row structure is 
followed by N column structures specified in the Number- 
Columns field. Note that this is an optional section. But with 
appropriate profile data, the SAS client prefetcher perfor- 
mance can be increased. 

[0546] Row Structure: (Variable Number of Entries) 

[0547] FileNumber [4 bytes] : File Number of the row 
block 

[0548] BlockNumber [4 bytes]: Block Number of the 
row block 

[0549] NumberColumns [4 bytes]: number of blocks 
that foUows this block. This field determines the 
number of column structures following this field. 

[0550] Column Stnicture: (Variable Number of Entries) 

[0551] FileNumber [4 bytes]: File Number of the 
column block 

[0552] BlockNumber [4 bytes]: Block Number of the 
column block 

[0553] Frequency [4 bytes]: frequency the row block 
is followed by column block 

[0554] 6. Comment Section 

[0555] The comment section 3106 is used by the Builder 
to describe this AppInstallBlock in more detail. 

[0556] CommentLengthlsAnsi [1 byte]: 1 if string is 
ansi, 0 if Unicode format. 

[0557] CommentLength [4 bytes]: Byte size of the 
[0558] Comment [X bytes]: NuU terminating com- 
[0559] 7. Code Section 

[0560] The code section 3107 consists of the application- 
specific initialization code needed to run on the SAS client 
to setup the client machine for this particular application. 
This section may be empty if the default initialization 
procedure in the SAS ctient is able to setup the client 
machine without requiring any application-specific instruc- 
tions. On the Windows system, the code is a DLL file 
containing two exported function calls: lnstall( ), Uninstall( 
). The SAS chent loads the DLL and invokes the appropriate 
function calls. 

[0561] CodeLength [4 bytes]: Byte size of the code 

[0562] Code [X bytes]: Binary file containing the 
application-specific initiahzation code. On Win- 
dows, this is just a DLL file. 

[0563] 8. LicenseAgreement Section 
[0564] The Builder creates the license agreement section 
3108. The SAS client displays the license agreement text to 
the end-user before the apphcation is started for the first 
time. The end -user must agree to all licensing agreement set 
by the software vendor in order to use the application. 



[0565] LicenseTextlsAnsi [1 byte]: 1 if ansi, 0 if 
Unicode format. 

[0566] LicenseTextLength [4 bytes]: Byte size of the 
license text 

[0567] LicenseAgreement [X bytes]: NuU terminat- 
ing license agreement string 

Chent Installation and Execution of Streamed 
Apphcations 

[0568] Summary 

[0569] I'his section describes the process of installing and 
uninstalling streamed application on the chent machine. 
With respect to FIG. 32, the hfecycle of the Apphcation 
InstaU Block is shown. The Application Stream Builder 
3202 takes original application files 3201 and produces a 
corresponding Apphcation Install Block and Stream Apph- 
cation Set 3203. These two files get installed onto the 
application servers 3206. On the right side of the drawing, 
it shows how either the administrator or the user can 
subscribe to the application from either the client computer 
3208 or an administration computer 3207. Once the user 
logons onto the client computer 3208, the license and the 
AIB 3203 are acquired from the license 3205 and applica- 
tion servers 3206, respectively. 

[0570] The following are features of a preferred embodi- 
ment of the invention: 

[0571] 1. The streamed application installation process 
installs just the description of the application, not the total 
content of the application. After installing such description, 
the client system looks and feels similar to having installed 
the same app using a non-streamed method. This has the 
following benefits: 

[0572] a. Takes a very small fraction of the time to 
install the application. 

[0573] b. Takes a very small fraction of the disk 

[0574] c. Client does not have to wait for the entire 
application to be downloaded. This is particularly 
important to users with slow network connections. 

[0575] The application description is subsequenfly un- 

installed without requiring deleting the total contents of the 

application. This has the benefit that it takes a very small 

fraction of the time to uninstall the application. 

[0576] 2. Enhancing streamed application's performance 

by: 

[0577] a. Copying small portions of apphcation's 
code and data (pages) that are critical to perfor- 

[0578] b. Providing client with the initial profile data 
that can be used to perform pre-fetching. 

[0579] This has the following benefits: 

[0580] 1. User experiences smooth and predictable 
application launch. 

[0581] 2. Scalabihty of Application servers increases 
by reducing the number of client connections. 
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[0582] 3. An administrator can arrange applications to be 
installed automatically on client computers. Administrator 
can also arrange the installation on various client computers 
simultaneously without being physically present on each 
client computer. This has the following benefits: 

[0583] a. Users are not burdened with the process of 
installing streamed applications. 

[0584] b. Reduced administration expense. 
[0585] Overview of Components Relevant to the Install 
Process 

[0586] Subscription Ser\'er 3204: allows users to 
create accounts & to rent. 

[0587] License Server 3205: authenticates users & 
determines licensing rights to applications. 

[0588] Application Server 3206: provides apphcation 
bits to licensed users securely & efScicntly. 

[0589] Application Install Manager — a component 
installed on the streaming cKent that is responsible 
for installing and uninstalling streamed applications. 

[0590] Application Install Block ( All i) 3203— a rep- 
resentation of what gets installed on the client 
machine when a streamed application is installed. It 
contains portions of the application that are respon- 
sible for registering the apphcation with the client 
operating system and other data that enhances the 
execution of streamed application. 

[0591] Application Stream Builder 3202— prepro- 
ccsscs apps & prepares files to be installed on 
Application Server and data, such as AIB, to be 
installed by Client Application Installer. 

[0592] Stream Application Set 3203— a method of 
representing the total content of the application in a 
format that is optimal for streaming. 

[0593] Client Streaming File System — integrates cli- 
ent exec with paging from a special file system 
backed by remote network-accessed server-based 

[0594] Application Install Block (AIB) 

[0595] Installing and un-installing a stream apphcation 
requires an understanding of what AIB is and how it gets 
manipulated by the various components in the overall 
streaming system. AIB is physically represented as a data 
file with various different sections. Its contents include: 
[0596] Streamed apphcation name and identification 
number. 

[0597] Software License Agreement. 
[0598] Registry spoof set. 
[0599] File spoof set. 

[0600] SmaU number of application pages — initial 

[0601] Application Profile Data. 
[0602] AIBLifecycle 

[0603] The following describes the AIB lifecycle: 

[0604] 1. Using the process described in the section 
above concerning converting apps for stream deliv- 
ery and subsequent execution, an application install 



block is created by the Application Stream Builder. 
Initially, there will be one AIB per application, 
however, as the apphcation evolves via patches and 
service packs, new AIBs may need to be generated. 

[0605] 2. Using a process described in the section 
above regarding server-side performance optimiza- 
tion, AIB will get hosted by the application ser\'ers. 

[0606] 3. "Subscribing" the application by commu- 
nicating with the subscription server. Subscribing to 
an application requires a valid account with the ASP. 
Either the user or an administrator acting on the 
user's behalf can subscribe the application. In addi- 
tion, the application can be subscribed to from any 
computer on the Internet, not just the client machine 
where the application will be eventually installed. 
This allows an administrator to subscribe applica- 
tions for a group of users without worrying about 
individual cKent machines. 

[0607] 4. The client machine acquires the license for 
the apphcation from the license server. If the apph- 
cation was subscribed from the client machine itself, 
this step will happen automatically after subscribing 
to the application. If the subscription happened from 
a different machine, e.g., the administrator's 
machine, this step will happen when the user logg on 
the client machine. As an acknowledgment of having 
a valid license, the license server gives the client an 
encrypted access token. 

[0608] 5. Fetch the contents of AIB from the apph- 
cation server. This step is transparent and happens 
immediately after the preceding step. Since applica- 
tion server requires the client to possess a valid 
access token, it ensures that only subscribed and 
licensed users can install the streamed application. 

[0609] 6. The Application InstaU Manager (AIM) 
performs the act of instalhng the application infor- 
mation, as specified by the AIB, on the client system. 

[0610] Installing a Streamed Application 

[0611] AIM downloads AIB from the application server 
and takes the necessary steps in instalhng the apphcation 
description on the client system. It extracts pieces of infor- 
mation from AIB and sends messages to various other 
components (described later) to perform the installation. 
AIM also creates an Install-Log that can be used when 
un-installing the streamed application. 

[0612] 1. Display a license agreement to the user and 
wait for the user to agree to it. 

[0613] 2. Extract File Spoof Data and communicate 
that to the Chent File Spoofer. The hst of files being 
spoofed will be recorded in the Install-I^g. 

[0614] 3. Extract Registry Spoof Data and commu- 
nicate that to the Client Registry Spoofer. The list of 
Registries being spoofed will be recorded in the 
Install-Log. 

[0615] 4. Extract Initial Cache Content and commu- 
nicate that to the Client Prefetch Unit. 

[0616] .5. Extract Profile Data and communicate that 
to the Chent Prefetch Unit. 

[0617] 6. Save the Install-Log in persistent storage. 
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[0618] Un-Installing a Streamed Application 
[0619] Un-installation process relies on the Install-Log to 
know what specific items to un-install. Following steps are 
performed when un-installing and application: 

[0620] 1. Communicate with the Client Registry 
Spoofer to remove all registries being spoofed for the 
application being un-inslalled. 

[0621] 2. Communicate with the Client File Spoofer 
to disable aU files being spoofed for the apphcation 
being un-installed. 

[0622] 3. Communicate with the Chent Prefetch Unit 
to remove all Profile Data for the application being 
un-installed. 

[0623] 4. Communicate with the CKent Cache Man- 
ager to remove all pages being cached for the appli- 
cation being un-installed. 

[0624] 5. Delete the Install-Log. 

[0625] Client File Spoofer 

[0626] A file spoofer component is installed on the client 
machine and is responsible for redirecting file accesses from 
a local file system to the streaming file system. The spoofer 
operates on a file spoof database that is stored persistently on 
the client system; it contains a number of file maps with 
following format: 

[0627] [Original path of a local flle]« — »[New path of a 
file on streaming drive] 

[0628] Where "< — »" indicates a bi-directional map- 
ping between the two sides of the relationship shown. 

[0629] When a streamed application is installed, the hst of 
new files to spoof (found in AIB) is added to the file spoof 
database. Similarly, when a streamed application is un- 
instaUed, a list of files being spoofed for that apphcation is 
removed from the file spoof database. 
[0630] On clients running the Windows 2000 Operating 
System, the file spoofer is a kernel-mode driver and the 
spoof database is stored in the registry. 
[0631] Client Registry Spoofer 

[0632] I'he Registry Spoofer intercepts aU registry calls 
being made on the client system and re-directs calls manipu- 
lating certain registries to an alternate path. Effectively, it is 
mapping the original registry to an alternate registry trans- 
parently. Similar to the client file spoofer, the registry 
spoofer operates on a registry spoof database consisting 
entries old/new registry paths. The database must be stored 
in persistent storage. 

[0633] When a streamed application is installed, the hst of 
new registries to spoof (found in AIB) is added to the 
registry spoof database. Upon un-installation of a streamed 
application, its list of spoofed registries is removed from the 
registry spoof database. 

[0634] On clients running the Windows 2000 Operating 
System, the registry spoofer is a kernel-mode driver and the 
registry spoof database is stored in the registry. 
[0635] Client Prefetch Unit 

[0636] In a streaming system, it is often a problem that the 
initial invocation of the application takes a lot of time 
because the necessary application pages are not present on 
the client system when needed. A key aspect of the client 



instaU is that by using a client prefetch unit, a system in 
accordance with the present invention significantly reduces 
the performance hit associated with fetching. The Client 
Prefetch Unit performs two main tasks: 

[0637] 1. Populate Initial Cache Content, 

[0638] 2. Prefetch Application Pages. 

[0639] Initial Cache Content 

[0640] The Application Stream Builder determines the set 
of pages critical for the initial invocation and packages them 
as part of the AIB. These pages, also known as initial cache 
content, include: 

[0641] Pages required to start and stop the applica- 

[0642] Contents of frequently accessed directories, 

[0643] Application pages performing some of the 
most common operations within apphcation. For 
example, if Microsoft Word is being streamed, these 
operations include: opening & saving document files 
& running a spell checker. 

[0644] When the Stream Apphcation is installed on the 
client, these pages are put into the chent cache; later, when 
the streamed application is invoked, these pages will be 
present locally and network latency is avoided. 

[0645] In preparing the Prefetch data, it is critical to 
manage the trade off of how many pages to put into AIR and 
what potential benefits it brings to the initial apphcation 
launch. Ilie more pages that are put into prefetch data, the 
smoother the initial application launch wih be; however, 
since the AIB wiU get bigger (as a result of packing more 
pages in it), users wiU have to wait longer when installing 
the streamed application. In a preferred embodiment of the 
invention, the size of the AIB is limited to approximately 
250 KB. 

[0646] In an alternative embodiment of the invention the 
AIB initially includes only the page/file numbers and not the 
pages themselves. The client then goes through the page/file 
numbers and does paging requests to fetch the indicated 
pages from the server. 

[0647] Prefetch Application Pages 

[0648] When the streaming application executes, it will 
generate paging requests for pages that are not present in the 
client cache. The client cache manager must contact the 
application server and request the page in question. The 
invention takes advantage of this opportunity to also request 
additional pages that the application may need in the future. 
This not only reduces the number of connections to the 
application server, and overhead related to that, but also 
hides the latency of cache misses. 

[0649] The apphcation installation process plays a role in 
the pre-fetching by communicating the profile data present 
in the AIB to the Client Prefetch Unit when the apphcation 
is installed. Upon un-installation, profile data for the par- 
ticular apphcation will be removed. 
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[0650] Summary 

[0651] This section describes how collaborative caching is 
employed to substantially improve the performance of a 
client server system in accordance with the other aspects of 
the present invention. Specifically, particular caching con- 
figurations and an intelligent way to combine these caching 
configurations are detailed. 

[0652] Collaborative Caching Features: 

[0653] Using another client's cache to get required 
pages/packets (Peer Caching) 

[0654] Using an intermediate proxy or node to get 
required pages/packets (Proxy Caching) 

[0655] Using a broadcasting or multicasting mecha- 
nism to make a request (Multicast) 

[0656] Using a packet based protocol to send 
requested pages/packets rather than a stream based 
one. (Packet Protocol) 

[0657] Using concurrency to request a page through 
all three means (Peer Caching or Proxy Caching or 
the actual server) to improve performance (Concur- 
rent Requesting). 

[0658] Using heuristical algorithms to use aU three 
ways to get the required pages (Smart Requesting). 

[0659] These features have the following advantages: 

[0660] These ideas potentially improve the perfor- 
mance of the client, i.e., they reduce the time a client 
takes to download a page (Client Performance). 

[0661] These ideas improve the scalability of the 
server because the server gets fewer requests, i.e., 
requests which are fulfilled by a peer or a proxy don't 
get sent to the server. (Server Scalabihty) 

[0662] These allow a local caching mechanism with- 
out needing any kind of modification of local proxy 
nodes or routers or even the servers. The peer-to-peer 
caching is achieved solely through the co-operation 
of two clients. (Client Only Implementation) 

[0663] These ideas allow a client to potentially oper- 
ate "offline" i.e., when it is not getting any responses 
from the server (Offline Client Operation). 

[0664] These ideas allow the existing network band- 
width to be used more effectively and potentially 
reduce the dependency of applications on higher 
bandwidth (Optimal Use of Bandwidth). 

[0665] These ideas when used in an appropriate con- 
figuration allow each client to require a smaller local 
cache but without substantially sacrificing the per- 
formance that you get by local caching. An example 
is when each client "specializes" in caching pages of 
a certain kind, e.g., a certain apphcation. (Smaller 
Local Cache). 

[0666] These ideas involve new interrelationships — ^peer- 
to-peer communication for cache accesses; or new configu- 
rations — collaborative caching. The reason this is called 
collaborative is because a group of clients can collaborate in 
caching pages that each of them needs. 



[0667] Aspects of Collaborative Caching 

[0668] f . Peer Caching: A client X getting its pages 
from another chent Y's local cache rather than its 
(X's) own or from the server seems to be a new idea. 
Major advantages: client performance, server scal- 
ability, client only implementation, offline client 
operation, optimal use of bandwidth, smaller local 

[0669] 2. Proxy Caching: The client getting its pages 
from an intermediate proxy which either serves the 
page from the local cache or from another interme- 
diate proxy or the remote server (if none of the 
intermediate proxies has the page) is unique, at a 
minimum, for the pages of a streamed application. 
Major advantages: client performance, server scal- 
abihty, offline client operation (to some extent), 
optimal use of bandwidth, smaller local cache. 

[0670] 3. Multicast: Using mulficasting (or selective 
broadcasting) considerably reduces peer-to-peer 
communication. For every cache request there is 
only one packet on the network and for every cache 
response there is potentially only one packet on the 
network in some configurations. This definitely helps 
reduce network congestion. Major advantages: client 
performance, server scalability, client only imple- 
mentation, offline client operation, optimal use of 
bandwidth 

[0671] 4. Packet Protocol: Because only datagram 
packets are used to request or respond to cache pages 
this saves the overhead of opening stream-based 
" s such as a TCP connection or an HTTP 
. Major advantages: client performance, 
chent only implementation, offline chent operation, 
and optimal use of bandwidth. 
[0672] 5. Concurrent Requesting: If concurrent or 
intelligently staggered requests through all three 
means are issued to request a single page, the client 
will be able to receive the page through the fastest 
means possible for that particular situation. Major 
advantages: client performance, server scalability, 
offline client operation, and optimal use of band- 

[0673] 6. Smart Requesting: An adaptive or "smart" 
algorithm can be used to further enhance the overall 
performance of the client-ser\'er system. In this algo- 
rithm, the client uses the data of how past requests 
were processed to "tune" new requests. For example, 
if the client's past requests were predominantly 
served by another client, i.e.. Peer Caching worked, 
then for new page requests the client would first try 
to use Peer Caching, and wait some time before 
resorting to either Proxy Caching or direct server 
request. This wait time can again be calculated in an 
adaptive fashion. Major advantages: client perfor- 
mance, server scalabihty, chent only implementa- 
tion, offline client operation, and optimal use of 
bandwidth. 

[0674] The concepts illustrated herein can be applied to 
many different problem areas. In all client-server implemen- 
tations where a server is serving requests for static data, e.g., 
code pages of a streamed application or static HTML pages 
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from a Website, the approaches taught herein can be applied 
to improve the overall cKent-ser\'er performance. Even if 
some of the protocols or configurations described in this 
document are not supported by the underlying network, it 
does not preclude the application of other ideas described 
herein that do not depend on such features. For example, if 
multicast (or selective broadcast) is not supported, ideas 
such as Concurrent Requesting or Smart Requesting can still 
be used with respect to multiple servers instead of the 
combination of a server, peer, and proxy. Also the use of 
words like Multicast does not restrict the apphcation of these 
ideas to multicast based protocols. These ideas can be used 
in all those cases where a multicast like mechanism, i.e., 
selective broadcasting is available. Also note that the 
description of these ideas in the context of LAN or intranet 
environment does not restrict their application to such 
environments. The ideas described here are applicable to any 
environment where peers and proxies, because of their 
network proximity, offer significant performance advantages 
by using Peer Caching or Proxy Caching over a simple 
client-server network communication. In that respect, the 
term LAN or local area network should be understood to 
mean more generally as a collection of nodes that can 
communicate with each other faster than with a node outside 
of that collection. No geographical or physical locality is 
implied in the use of the term local area network or LAN. 
[0675] Peer Caching 

[0676] Referring to FIG. 33, how multiple peers collabo- 
rate in caching pages that are required by some or all of them 
is shown. 

[0677] The main elements shown are: 

[0678] CHent 13301 through Chent 63306 in an Eth- 
ernet LAN 3310. 

[0679] Router 1 and the local proxy serving as the 
Internet gateway 3307. Note that it does not matter 
whether Router 1 and the proxy are one computer or 
two different ones. 

[0680] Other routers from router 2 through router N 
3308 that are needed to connect the LAN 3310 to the 
Internet 3311. 

[0681] A remote server 3309 (that is reachable only 
by going over the Internet 3311) that is serving the 
pages that the above mentioned clients need. 

[0682] A cloud that symbohzes the complexity of the 
Internet 3311 and potentially long paths taken by 

[0683] Client 23302 needs a page that it does not find in 
its local cache. It then decides to use the mechanism of Peer 
Caching before attempting to get the page from the local 
proxy (or the actual server through the proxy). The actual 
sequence of events is as follows: 

[0684] 1. Client 23302 sends a request for the page it 
needs. Iliis request is sent as a multicast packet to a 
predetermined multicast address and port combina- 
tion. Lets call this multicast address and port com- 
bmation as M. 

[0685] 2. The multicast packet is received by all the 
clients that have joined the group M. In this case all 
six cHents have joined the group M. 



[0686] 3. Client 53305 receives the request and it 
records the sender's, i.e.. Client 2's 3302, address 
and port combination. Let's assume this address and 
port combination is A. Chent 53305 processes the 
request and looks up the requested page in its own 
cache. It finds the page. 

[0687] 4. Client 53305 sends the page to address A 
(which belongs to Chent 23302) as a packet. 

[0688] 5. Client 23302 receives the page it needs and 
hence does not need to request the server for the 
page. 

[0689] Proxy Caching 

[0690] With respect to FIG. 43, a transparent proxy and 
how clients use it to get pages is shown. Again the elements 
here are the same as in the previous figure: 

[0691] CHent 13401 through Client 63406 in an Eth- 
ernet LAN 3410. 

[0692] Router 1 and the local proxy serving as the 
Internet gateway 3407. Note that it does not matter 
whether Router 1 and the proxy are one computer or 
two different ones. 

[0693] Other routers from router 2 through router N 
3408 that are needed to connect the LAN 3410 to the 
Internet 3411. 

[0694] A remote server 3409 (that is reachable only 
by going over the Internet 3411) that is serving the 
pages that the above mentioned clients need. 

[0695] A cloud that symbohzes the complexity of the 
Internet 3411 and potentially long paths taken by 
packets. 

[0696] Assume Peer Caching is either not enabled or did 
not work for this case. When Client 23402 needs a page, it 
makes a request to the proxy 3407. The proxy 3407 finds the 
page in its local cache and returns it to Client 23402. 
Because of this, the request did not go to the remote server 
3409 over the Internet 3411. 

[0697] Muhicast and Packet Protocol Within a LAN 

[0698] Referring to FIG. 35, the role played by muhicast 
and unicast packets in Peer Caching is shown. The example 
of the drawing "Peer Caching" is used to explain multicast. 
Here Client 23502 has the IP address 10.0.0.2 and it opens 
port 3002 for sending and receiving packets. When Client 
23502 needs a page and wants to use Peer Caching to get it, 
it forms a request and sends it to the multicast address and 
port 239.0.0.1:2001. All the other clients in the LAN 3508 
that support Peer Caching have already joined the group 
239.0.0.1:2001 so they all receive this packet. 

[0699] Chent 53505 receives this packet and it records the 
sender address (10.0.0.2:3002 in this case). It looks up the 
requested page and finds it in its local cache. It sends the 
page as a response packet to the address 10.0.0.2:3002. 

[0700] Chent 23502 receives this response packet since it 
was waiting at this port alter sending the original multicast 
request. After ensuring the validity of the response, it 
retrieves the page it needs. 
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[0701] Note that more than one dient can respond to the 
original multicast request. However Client 23502 can dis- 
card all the later responses, since it has already received the 
page it needed. 

[0702] Concurrent Requesting — Proxy First 
[0703] With respect to FIG. 36, one particular case of how 
Concurrent Requesting is used is shown. This is a timeline 
of events that take place in the client. When a cKent first 
needs a page, it does not know whether it is going to get any 
responses through Peer Caching or not. Hence it issues a 
request to the proxy (or the server through the proxy) as soon 
as it needs the page. Then it issues a request using the Peer 
Caching mechanism. If there is indeed a peer that can return 
the page requested, the peer presumably could return the 
page faster than the proxy or the server. If this happens, the 
client may decide to use Peer Caching mechanism before 
attempting to get the page from the proxy or the server. The 
timeline csscntiaUy describes the foUowing sequence of 

[0704] 1. At time t=0, a page p is needed by the chent 
3601 

[0705] 2. The client looks up its local cache, and it 
doesn't find page p. 

[0706] 3. At time t=Tl, it decides to send a request to 
the proxy to get the page 3602. 

[0707] 4. After a delay of amount 3603, at time 
t=T2 it also sends a request for the page p through the 
mechanism of Peer Caching 3604. Note that Dp 3603 
can be zero, in which case T1=T2. 

[0708] 5. At time 1=13, a response is received from 
another peer that contains the page p that this client 
needs 3606. Thus the response time of the Peer 
Caching mechanism is Rp=T3-T23605. 

[0709] 6. At time t='l'4, a response from the proxy/' 
server is received that contains the page p 3608. 
Hence the response time of the proxy/server is 
R,=T4-T13607. 

[0710] Note that since, Rp<R„ the client wiU increase the 
weighting for Peer Caching in all of its future queries. That 
means it will decrease Dp, and if Dp is already zero, it will 
increase D^ (the delay before requesting proxy/server). On 
the other hand, if Rp>R„ or if Rp were infinity, it will increase 
its weighting for proxy/server requesting. This is part of 
Smart Requesting that is explained elsewhere in this docu- 

[0711] Concurrent Requesting — Peer Caching First 
[0712] Referring to FIG. 37, in contrast to the previous 
figure, the client has decided to use Peer Caching before 
requesting the proxy. So the sequence of events is as 
follows: 

[0713] 1. At time t=0, a page p is needed by the chent 
3701. 

[0714] 2. The client looks up its local cache, and it 
doesn't find page p. 

[0715] 3. At time t=T5, it decides to send a request for 
the page p through the mechanism of Peer Caching 
3702. 



[0716] 4. After a delay of amount D, 3703, at time 
t=T6 it also sends a request for the page p to the 
proxy/server. Note that D^ can be zero, in which case 
T5=T6. 

[0717] 5. At time t=T7, a response is received from 
another peer that contains the page p that this client 
needs 3706. Thus the response time of the Peer 
Caching mechanism is Rp=T7-T53705. 

[0718] 6. At time t=T8, a response from the proxy/ 
server is received that contains the page p 3708. 
Hence the response time of the proxy/server is 
R,=T8-T63707. 

[0719] As described in the previous drawing, the client 
increases the weighting of Peer Caching even more because 
it got a response through Peer Caching long before it got a 
response from the proxy/server. As a result of the increases 
weighting the delay D^ is increased even more. 
[0720] Concurrent Requesting — Peer Caching Only 
[0721] With respect to FIG. 38, in contrast with FIG. 37, 
the client has increased D^ 3805 (the delay before requesting 
a proxy/server) so much, that if a page is received before the 
expiry of the delay D, 3805, the chent does not even make 
a request to the proxy/server. The shaded area 3806 shows 
the events that do not take place because of this. 

[0722] Chent-Server System with Peer and Proxy Caching 
[0723] Referring to FIG. 39, a system level drawing that 
gives a system context for all the other figures and discus- 
sion in this document is shown. This drawing illustrates all 
three ways in which a client gets its page requests fulfilled. 
Note that: 

[0724] Chent 23902 gets its page request fulfiUed 
through Peer Caching, i.e., muUicast request. 

[0725] Chent 13901 gets its page request fulfiUed 
through Proxy Caching, i.e., the proxy 3907 finds the 
page in its cache and returns it. 

[0726] Chent 33903 has to go to the server 3909 over 
the Internet 3908 to get its page request fulfilled. 

[0727] CoUaborative Caching Details 
[0728] In a typical client-server model, caching could be 
used to improve the performance of clients and scalability of 
servers. This caching could be: 

[0729] Local to the chent where the client itself 
locally stores the pages it had received from the 
server in the past. Then the chent would not need to 
request the proxy/server for any page that resides in 
the local cache as long as the locally cached page is 
"valid" from the server point of view. 

[0730] On a proxy node that can be any node along 
the path taken by a packet that goes from the client 
to the server. The closer this proxy node is to the 
chent the more improvement in the performance you 

[0731] On a peer node, that is on another client. In 
this case, the two clients (the requesting client as 
weh as the serving client) are on the same LAN or 
intranet, so that the travel time of a packet between 
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the two nodes is considerably smaller as compared to 
the travel time of the packet from one of the clients 
to the server. 

[0732] As far as caching is concerned, this section details 
the new ideas of Peer Caching and Proxy Caching. In 
addition, it also details the new ideas of Concurrent Request- 
ing and Smart Requesting. The preferred approaches for 
implementing these ideas are also described here and these 
are Multicast and Packet Protocol. 

[0733] The idea of Peer Caching is nothing but a client X 
taking advantage of the fact that a peer, e.g., say another 
client Y, on its LAN had, in the past, requested a page that 
X is going to request from its server. If the peer Y has that 
page cached locally on its machine, then X could theoreti- 
cally get it much faster from Y than getting it from the server 
itself. If an efficient mechanism is provided for the two 
clients X and Y to collaborate on this kind of cache access, 
then that will offer many advantages such as: Client Perfor- 
mance, Server Scalability, Client Only Implementation, 
Offline Client Operation, Optimal Use of Bandwidth, 
Smaller Local Cache. Note that two clients were considered 
only as an example, the idea of Peer Caching is applicable 
to any number of peers on a LAN. 

[0734] The idea of Multicast is to use the multicast pro- 
tocol in the client making a Peer Caching request. Multicast 
can be briefly described as "selective broadcasting" — simi- 
lar to radio. A radio transmitter transmits "information" on 
a chosen frequency, and any receiver (reachable by the 
transmitter, of course) can receive that information by tuning 
to that frequency. In the realm of multicast, the equivalent of 
a radio frequency is a multicast or class D IP address and 
port. Any node on the net can send datagram packets to a 
multicast IP address+port. Another node on the net can 
"join" that IP address+port (which is analogous to tuning to 
a radio frequency), and receive those packets. That node can 
also "leave" the IP address+port and thereby stop receiving 
multicast packets on that IP address+port. 

[0735] Note that multicast is based on IP (Internet Proto- 
col) and is vendor neutral. Also, it is typically available on 
the Ethernet LAN and, if routers supported it, it can also go 
beyond the LAN. If all the routers involved in a node's 
connection to the Internet backbone supported multicast 
routing, multicast packets theoretically could go to the 
whole Internet except the parts of the Internet that do not 
support multicast routing. 

[0736] The use of multicast allows a client to not have to 
maintain a directory of peers that can serve its page requests. 
Also because of multicast there is only one packet per page 
request. Any peer that receives the request could potentially 
serve that request, so by using a multicast based request 
there are multiple potential servers created for a page request 
but only one physical packet on the network. This contrib- 
utes substantially in reducing network bandwidth, but at the 
same time increasing peer accessibility to all the peers. 
When implemented properly, the packet trafBc due to Peer 
Caching will be proportional to the number of clients on the 
network participating in Peer Caching. 

[0737] An idea related to Multicast is Packet Protocol. 
Note that Multicast itself is a packet-based protocol as 
opposed to connection based. The idea of Peer Caching here 
is described using Multicast and Packet Protocol. The Peer 



Caching request is sent as a multicast request and the 
response from a peer to such a request is also sent as a packet 
(not necessarily a multicast packet). Sending packets is 
much faster than sending data through a connection-based 
protocol such as TCP/IP, although using packet-based pro- 
tocol is not as rehable as using connection-based one. The 
lack of reUability in Packet Protocol is acceptable since Peer 
Caching is used only to improve overall performance of the 
Client-Server system rather than as a primary mechanism for 
a cUent to get its pages. The underlying assumption made 
here is that a client could always get its pages from the 
server, if Peer Caching or Proxy Caching does not work for 

[0738] The ideas of Concurrent Requesting and Smart 
Requesting describe how Peer Caching, Proxy Caching and 
client-server access could be combined in an intelligent 
fashion to achieve optimal performance of the whole Client- 
Server system. As part of Concurrent Requesting, a chent is 
always prepared to make concurrent requests to get the page 
it needs in the fastest way possible. Concurrent Requesting 
would require the use of objects such as threads or processes 
that would allow one to programmatically implement Con- 
current Programming. This document assumes the use of 
threads to describe a possible and preferred way to imple- 
ment Concurrent Requesting. 

[0739] The idea of Smart Requesting includes using an 
adaptive algorithm to inteUigently stagger or schedule 
requests so that a client, even while using Concurrent 
Requesting, would not unnecessarily attempt to get a page 
through more than one means. An example of this is when 
a client has consistently gotten its page requests fulfilled 
through Peer Caching in the past. It would come to depend 
on Peer Caching for future page requests more than the other 
possible means. On the other hand, if Peer Caching has not 
worked for that client for some time, it would schedule a 
proxy request before a Peer Caching request. Smart Request- 
ing involves dynamically calculating the delays Dp and 
based how well Peer Caching and Proxy Caching has 
worked for the client. Please see FIGS. 36 through 38. 

[0740] The following is an algorithmic description using 
pseudo-code of an illustrative embodiment. 

[0741] startOurClient is a function that is invoked initially 
when the client is started. 



Initialize the global variable delav to appropriate value based on a 
predfined policy. When delay is positive, it signifies the amount of 
time to wait after Proxy Caching before Peer Caching is attempted; 




[0742] The function getPage is called by the client's 
application to get a page. This function looks up the local 
cache and if the page is not found, attempts to get the page 
from a peer or proxy/server using the ideas of Concurrent 
Requesting and Smart Requesting. 
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niqucly identifies the page 
:t to 239.0.0.1:2001 tlirougli 



;d by gotPage being signaled { 



socket X and pageld as aij 

id peeiResponse(socket X, p 
Wait at the socket X for a 
If a packet was received a 
Uncompress the pack 
Validate the packet ar 



geld); 



Call requestProxv(pageld); 

} 

Depending on how the page came (through Proxy Cacl 



[0743] The function requestProxy sends a page request to 
the proxy and starts a thread that waits for the page response 
(or times out). The function proxy Response is the thread 
function that waits for the response based on the arguments 



[0745] The function peerServer described below serves 
page requests received through Peer Caching as multicast 
packets. The function below describes how this thread 
would work: 



a response was received at socket X { 
Uncompress the packet if necessary: 
Validate the packet and ensure that thii 



Wait at M for a mult: 
Store the'lource IP addr ii 



// this IS time out: dichi t receive any Piracy Prevention for Streamed Applications 

^ Set appropriate indicator to indicate time-out; [0746] Summary 

Signal an event to signify completion of this thread; |-0747] The details presented in this section describe new 
re uestPeer and eerRes onse functions techniques of the invention that have been developed to 
combat software piracy of applications provided over net- 
works, in situations where an ASP's clients' machines 
. ^ . .... execute the software applications locally. The remote ASP 
[0744] The function requestPeer is similar to requestProxy ^^^^^^ ^^^j ^^^^ gj^^ ^^^^ constitute an apphcation 
except that it sends a page request to peers and starts a thread available to any subscribed user, because it cannot predict 
that waits for the page response (or times out). The function ^ith complete accuracy which files are needed at what point 
peerResponse is the thread function that waits for the 
response based on the arguments passed to it. 
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client computer that could be useful at stopping piracy. The 
process may be a rogue process intent on pirating the data, 
or it may be a secure process run from an executable 
provided by the ASP. 

[0748] Aspects of the Invention 

[0749] 1. Client-side fine-grained filtering of file 
accesses directed at remotely served files, for anti- 
piracy purposes. Traditional network filesystems per- 
mit or deny file access at the server side, not the 
client side. Here, the server provides blanket access 
to a given user to all the files that the user may need 
during the execution of an apphcation, and makes 
more intelligent decisions about which accesses to 
permit or deny. 

[0750] 2. Filtering of file accesses based on where the 
code for the process that originated the request is 
stored. Traditional file systems permit or deny file 
access usually based on the credentials of a user 
account or process token, not on where the code for 
the process resides. Here, a fllesystem may want to 
take into account whether the code for the originat- 
ing process resides in secure remote location or an 
insecure local location. 

[0751] 3. Identification of crucial portions of served 
files and filtering file accesses depending on the 
portion targeted. The smallest level of granularity 
that traditional file systems can operate on is at the 
level of files, not at the level of the sections con- 
tained in the files (for example, whether or not data 
from a code section or a resource section is 
requested). 

[0752] 4. Filtering of file accesses based on the 
surmised purpose of the file access, as determined by 
examining the program stack or flags associated with 
the request. Traditional file systems do not attempt to 
determine why a file access was issued before per- 
mitting or denying the access, e.g., whether the 
purpose is to copy the data or page in the data as code 
for execution. 

[0753] 5. Filtering of file accesses based on the 
surmised purpose of the file access, as determined by 
examining a history of previous file accesses by the 
same process. Traditional file systems do not keep 
around histories of which blocks a given requestor 
had previously requested from a file. This history can 
be useful in seeing if the requests match a pattern that 
suggests a file copy is occurring as opposed to code 

[0754] Benefits of the Anti-Piracy Features of the Present 
Invention 

[0755] This is an enabler technology that allows a pro- 
grammer to build security into a certain type of apphcation 
delivery system that would otherwise not be possible. Sev- 
eral companies are developing technology that allows an 
application to be served remotely, but executed locally. 
Current filesystems provide no way to protect the files that 
make up this application from being copied and thus pirated. 
The above techniques are tools that enable a filesystem to 
allow just those requests that will let the application run 
normally and block those that are the result of attempts to 



pirate the application's code or data. This provides a com- 
petitive advantage to those software providers who use this 
technology, because piracy results in lost revenue and, by 
preventing this, piracy they can prevent this loss. 

[0756] The techniques described herein were developed 
for the purpose of preventing the piracy of computer soft- 
ware programs that are served from a remote server, but 
executed on a local client. However, they can be used by any 
computer software security solution that would benefit from 
the abihty to filter file accesses with more flexibility than 
currently provided by most filesystems. 

[0757] When a filesystem receives a request, it must 
decide whether or not the request should be granted or 
denied for security reasons. If the target file is local, the 
filesystem makes the decision by itself, and if the target file 
is remote, it must ask the server to handle the request for it. 
The above techniques are ways in which the filesystem can 
gather more information about the request than it would 
ordinarUy have. It can then use that information to improve 
the quality of its decisions. Traditional approaches, such as 
granting a currently logged-in user access to certain files and 
directories that are marked with his credentials, are not 
flexible enough for many situations. As for remote files, the 
server has only a limited amount of information about the 
client machine. The filesystem at the client side can make 
grant/deny decisions based on local information before ever 
asking the server, in order to provide a more inteUigent layer 
of security. 

[0758] For example, it may be desirable to allow the user 
to execute these files, but not copy them. It may be desirable 
to grant access to only certain processes run by the user, but 
not others, because it is judged that some processes to be 
more secure or well-behaved than others. And it may be 
desirable to allow the user to access only certain sections of 
these files and from only certain processes for certain 
periods of time. The above techniques are tools that are 
added to a filesystem to give it these abilities. 

[0759] Overview of the Anti-Piracy Features of the 
Present Invention 

[0760] With respect to FIG. 40, preventing piracy of 
remotely ser\'ed, locally executed applications is shown. 
This figure illustrates the problem of software piracy in an 
application delivery system, and how it can be stopped using 
the techniques described in this section. The client computer 
4001 is connected to a server 4009 run by an ASP 4007. The 
server 4009 provides access to apphcation files 4008, out of 
which the application executable is run by the client 4001 
locally on his machine. (Tltis is Process #14002). However, 
the user can attempt to access and copy the application files 
to local storage 4009 on his machine, and thus be able to run 
them without authorization or give them to another person. 
But since aU requests directed at the remote files 4006 must 
first pass through the local network filesystem, this filesys- 
tem can be enhanced 4005 to deny all such requests that it 
thinks are the result of an attempt at piracy. 

[0761] Referring to FIG. 41, the filtering of accesses to 
remote apphcation files, illustrating New Technique #1, as 
described above is shown. (Note: the client computer rep- 
resented here and in all subsequent figures is part of the same 
client-server system as in FIG. 40, but the server/ASP 
diagram has been omitted to save space.) A user 4102 who 
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has been granted access to remotely served flies 4106 
representing an application is attempting to access these 
files. The local enhanced network filesystem 4103 is able to 
deny access to certain files 4105 and grant access to others 
4104, for the purpose of protecting critical parts of the 
application from piracy. 

[0762] With respect to FIG. 42, the filtering of accesses to 
remote flies based on process code location, illustrating New 
Technique #2, as described above, is shown. Here there are 
two processes on the client computer. Process #14202 has 
been run from an executable file 4206 that is part of a 
remotely served application 4207, and process #24203 has 
been run from a local executable file 4204. They are both 
attempting to access a remote data file 4206 that is part of the 
served application 4207. The local enhanced network file- 
system 4205 is denying Process #24203 access and granting 
Process #14202 access because Process #2's 4203 execut- 
able is stored locally, and thus is not secure, while Process 
#l's 4202 executable is provided by the server 4207, and 
thus can be vouched for. 

[0763] Referring to FIG. 43, the flltering of accesses to 
remote files based on targeted file section, illustrating New 
Technique #3, as described above, is shown. Here there is a 
single local process 4302 that is attempting to read from a 
remotely served executable file 4307. The enhanced network 
filesystem 4304 is denying an attempt to read from the code 
section 4306 of the file 4307 while granting an attempt to 
read from a non-code section 4305 of the file 4307. I'his is 
useful when access to some part of the file must be allowed, 
but access to other parts should be denied to prevent piracy 
of the entire file. 

[0764] With respect to FIG. 44, the filtering of accesses to 
remote files based on surmised purpose, illustrating New 
Technique #4 as described above, is shown. Here, two 
attempts to read from the code section 4407 of a remote 
executable file 4408 are being made from a process 4402 
that was run from this file 4408. However, one request is 
denied because it originated 4406 from the process's code 
4403 itself, while another is approved because it originated 
from code in the Virtual Memory Subsystem 4404. This 
prevents even a rogue remote process from attempting to 
pirate its own code, while allowing legitimate requests for 
the code to be completed. 

[0765] Referring to FIG. 45, the filtering of accesses to 
remote files based on past access history, illustrating New 
Technique #5 as described above, is shown. Here, two 
processes 4502, 4503 run from a local executable 4504 are 
attempting to access a remote file 4508. The enhanced 
network filesystem 4507 keeps around a history of previous 
file accesses by these processes 4505, 4506, which it con- 
sults to make decisions about permitting/denying further 
accesses. Process #1 's 4502 access attempt is granted, while 
Process #2's 4503 is denied, because the filesystem 4507 
detected a suspicious pattern in Process #2's 4503 previous 
access history 4506. 

[0766] Anti-Piracy Details of the Invention 

[0767] Five anti-piracy embodiments are disclosed below 
that can be used by an ASP-installed network filesystem to 
combat piracy of remotely served applications. The ASP 
installs a software component on the client that is able to 
take advantage of local knowledge, e.g., which process on 



the client originated a request for data, and permit or deny 
requests for remote files before sending the requests to the 
server. That is, a network filesystem is installed on the local 
user's computer that manages access to these remote files. 
All input/output requests to these files must pass through this 
filesystem, and if the filesystem determines that a given 
request is suspicious in some way, it has the freedom to deny 

[0768] Anti-Piracy Embodiment #1 
[0769] CKent-side fine-grained filtering of file accesses 
directed at remotely served files, for anti-piracy purposes. 
[0770] Referring again to FIG. 41, the approach of the 
first anti-piracy embodiment is that a software component 
4102 executing locally on a client computer 4101 has 
available to it much more information about the state of this 
computer than does a server providing access to remote files. 
Thus, the server can filter access only on a much coarser 
level that can this client component. An ASP can take 
advantage of this by installing a network filesystem 4103 on 
the cKent computer that is designated to handle and forward 
all requests directed at files located on a given remote server. 
This filesystem 4103 examines each request, and either 
grants or denies it depending on whether the request is 
justifiable from a security perspective. It can use information 
such as the nature of the originating process, the history of 
previous access by the process, the section of the targeted 
file being requested, and so on, in order to make its decision. 
[0771] The best way known of implementing this 
approach is to write a network redirector filesystem com- 
ponent 4103 for the operating system that the ASP's clients' 
machines will be running. This component will be installed, 
and will make visible to the system a path that represents the 
server on which the ASP's application files are stored. The 
local computer can now begin accessing these files, and the 
filesystem 4103 will be asked to handle requests for these 
files. On most operating systems, the filesystem 4103 will 
register dispatch routines to the system that handle common 
file operations such as open, read, write and close. When a 
local process 4102 makes a request of an ASP-scrvcd file, 
the OS calls one of these dispatch routines with the request. 
In the dispatch routine, the filesystem 4103 examines the 
request and decides whether to deny it or grant it. If granted, 
it wiU forward the request to the remote server and send back 
the response to the operating system. 

[0772] Anti-Piracy Embodiment #2 

[0773] Filtering of file accesses based on where the code 
for the process that originated the request is stored. 

[0774] Referring again to FIG. 42, when a filesystem 4205 
receives a request for access to a given file, the request 
always originates from a given process on the computer. By 
determining where the executable file that the process was 
run from is located, the network filesystem 4205 can make 
a more informed decision about the security risk associated 
with granting the request. For example, if the executable file 
4204 is located on the local computer 4202, then it may 
contain any code whatsoever, code that may attempt to copy 
and store the contents of any remote files it can gain access 
to. The filesystem 4205 can reject requests from these 
processes as being too risky. However, if the executable file 
4206 is being served by the ASP's remote server 4207, then 
the process can assume to be well-behaved, since it is under 
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the control of the ASP. The fllesystem 4205 can grant 
accesses that come from these processes 4202 in confidence 
that the security risks are minimal. 

[0775] The best way known of implementing this 
approach is to modify a network fllesystem 4205 to deter- 
mine the identity of the process that originated a relevant 
open, read, or write request for a remote file. On some OSes 
a unique process ID is embedded in the request, and on 
others, a system call can be made to get this ID. Then, this 
ID must be used to look up the pathname of the executable 
file from which the process was run. To do this, upon 
initialization the fllesystem 4205 must have registered a 
callback that is invoked whenever a new process is created. 
When this callback is invoked, the pathname to the process 
executable and the new process ID are provided as argu- 
ments, data which the fllesystem 4205 then stores in a data 
structure. This data structure is consulted while servicing a 
file request, in order to match the process ID that originated 
the request with the process's executable. Then the root of 
the pathname of that executable is extracted. The root 
uniquely identifies the storage device or remote server that 
provides the file. If the root specifles an ASP server that is 
known to be secure, as opposed to a local storage device that 
is insecure, then the request can be safely granted. 
[0776] Anti-Piracy Embodiment #3 
[0777] Identification of crucial portions of served flies and 
filtering file access depending on the portion targeted. 

[0778] Referring again to FIG. 43, a ser\'ed apphcation 
usually consists of many files. In order to steal the applica- 
tion, a pirate would have to copy at least those files that store 
the code for the appflcation's primary executable, and per- 
haps other flies as weU. This leads to the conclusion that 
some files are more important that others, and that some 
portions of some flies are most important of all. Ordinarfiy, 
the best solution would be to deny access to the primary 
executable flle and its associated executables in its entirety, 
but this is not usually possible. In order to initially run the 
application, the fllesystem 4304 must grant unrestricted 
access to some portions of the primary executable. In order 
to prevent piracy, the fllesystem 4304 can grant access 
selectively to just those portions that are needed. Addition- 
ally, the running application 4302 itself does not usually 
need to read its own code section, but does need to read other 
sections for purposes such as resource loading. Therefore, 
additional security can be introduced by denying access to 
the code sections 4306 of ASP-served executables 4307 
even to those executables themselves. 

[0779] To implement this, modify a network fllesystem's 
4304 open flle dispatch routine to detect when a remotely 
served executable 4307 is being opened. When this is 
detected, the executable flle 4307 is examined to determine 
the offset and length of its code section 4306, and this 
information is stored in a data structure. On most OSes, 
executable flies contain headers from which this information 
can be easily read. In the read and write dispatch routines, 
the network fllesystem 4304 checks if the request is for a 
remote executable 4307, and if so, the offset and length of 
the code section 4306 of this executable 4307 is read from 
the data structure in which it was previously stored. Then the 
ofl'set and length of the request are checked to see if they 
intersect the code section 4306 of this executable 4307. If so, 
the request can be denied. 



[0780] Anti-Piracy Embodiment #4 

[0781] Filtering of flle accesses based on the surmised 
purpose of the file access, as determined by examining the 
program stack or flags associated with the request. 

[0782] Referring again to FIG. 44, the approach of the 
fourth embodiment is that identical requests from the same 
process for a remotely served file can be distinguished based 
on the reason the request was issued. For example, on a 
computer with a virtual memory subsystem 4404, the 
VMS's own code wfil be invoked to page-in code for a 
process that attempts to execute code in pages that are not 
currently present. To do this, the VMS 4404 must issue a 
read request to the filesystem 4405 that handles the process" 
4402 executable file 4408. Since this request is not for any 
ulterior purpose, such as piracy, and is necessary for the 
application to execute, the request should be granted. If the 
filesystem 4405 gets the originating process ID for such 
requests, the process whose code is being paged in will be 
known. However, this same process ID will also be returned 
for requests that originate as a result of an attempt by the 
process itself to read its own code (perhaps for the purpose 
of piracy). Many applications have loopholes that allow the 
user to execute a macro, for example, that reads and writes 
arbitrary flies. If the fllesystem 4405 simply flkers requests 
based on process IDs, it will mistakenly allow users to pirate 
remotely served applications, as long as they can send the 
necessary reads and writes from within the remote applica- 
tion itself 

[0783] However, even if the process IDs are the same for 
two apparently identical requests, there are ways the flle- 
system 4405 can distinguish them. There are two known 
ways to do this in a manner relevant to combating anti- 
piracy. The way to implement the first method is to have the 
filesystem 4405, upon receiving a read request, check for the 
presence of the paging I/O flag that is supported by several 
operating systems. If this flag is not present, then the request 
did not come from the VMS 4404, but from the process itself 
4403, and thus the request is risky and not apparentiy 
necessary for the application to run. If the flag is present 
though, the request almost certainly originated from the 
VMS 4404 for the purpose of reading in code to allow the 
process to execute. The request should be allowed. 

[0784] Another way to make this same determination is to 
have the fllesystem 4405 examine the program stack upon 
receiving a read request. In several operating systems, a 
process will attempt to execute code that resides in a virtual 
page regardless of whether the page is present or not. If the 
page is not present, a page fault occurs, and a structure is 
placed onto the stack that holds information about the 
processor's current state. Then the VMS 4404 gets control. 
The VMS 4404 then caUs the read routine of the fllesystem 
4405 that handles the process's executable flle to read this 
code into memory. The filesystem 4405 now reads back- 
wards up the stack up to a certain point, searching for the 
presence of the structure that is placed on the stack as a result 
of a page fault. If such a structure is found, the execution 
pointer register stored in the structure is examined. If the 
pointer is a memory address within the boundary of the 
virtual memory page that is being paged in, then the flle- 
system 4405 knows the read request is legitimate. 
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[0785] Anti-Piracy Embodiment #5 
[0786] Filtering of file accesses based on the surmised 
purpose of tlie file access, as determined by examining a 
iiistory of previous file accesses by the same process. 

[0787] Referring again to FIG. 45. if one loolis at the 
series of file requests that are typically made as a result of 
attempting to copy an executable file, as opposed to those 
made in the course of executing that file, one can see certain 
patterns. The copy pattern is usually a sequence of sequen- 
tially ordered read requests, while the execution pattern 
tends to jump around a lot (as the result of code branches 
into non-present pages). A filesystem can be enhanced to 
keep around a history of requests made by specific processes 
on remotely served files. Then, for every subsequent request 
to such a file, the history for the originating process can be 
examined to check for certain patterns. If a file-copy pattern 
is seen, then the pirate may be attempting to steal the file, 
and the request should be denied. If an execution type 
pattern is seen, then the user is simply trying to run the 
application, and the request should be granted. 
[0788] To implement this, a filesystem 4507 will tell the 
operating system, via an operating system call, upon initial- 
ization, to call it back whenever a new process is created. 
When it is called back, the filesystem 4507 will create a new 
data structure for the process that will store file access 
histories 4505, 4506. Then, in its read-file dispatch routines, 
the filesystem 4507 will determine the process ID of the 
originating process, and examine the process's access his- 
tory 4505, 4506. It will only examine entries in that history 
4505, 4506 that refer to the file currently being requested. It 
will then run a heuristic algorithm that tries to determine if 
the pattern of accesses more closely resembles an attempted 
file copy than code execution. An eflective algorithm is to 
simply see if the past n read requests to this file have been 
sequential, where n is some constant. If so, then the request 
is denied. If not, then the request is granted. In either case, 
an entry is made to the filesystem's process access history 
4505, 4506 that records the file name, offset, and length of 
the request made by that process to this file. 

Conclusion 

[0789] Although the present invention has been described 
using particular illustrative embodiments, it will be under- 
stood that many variations in construction, arrangement and 
use are possible within the scope of this invention. Other 
embodiments may use different network protocols, different 
programming techniques, or different heuristics, in each 
component block of the invention. Specific examples of 

[0790] The proxy used in Proxy Caching could be 
anywhere in the Internet along the network path 
between a Client and the Server; and 

[0791] Concurrent Requesting and Smart Requesting 
can be implemented in hardware instead of software. 

[0792] A number of insubstantial variations are possible in 
the implementation of anti-piracy features of the invention. 
For example, instead of modifying the filesystem proper to 
provide anti-piracy features, a network proxy component 
can be placed on the client computer to filter network 
requests made by a conventional local network filesystem. 
These requests generally correspond to requests for remote 



files made to the filesystem by a local process, and the type 
of filtering taught by the present invention can be performed 
on these requests. A filesystem filter component can also be 
written to implement these methods, instead of modifying 
the filesystem itself. 

[0793] Although the invention is described herein with 
reference to the preferred embodiment, one skilled in the art 
will readily appreciate that other applications may be sub- 
stituted for those set forth herein without departing from the 
spirit and scope of the present invention. Accordingly, the 
invention should only be limited by the Claims included 

1. A process for converting a conventionally coded com- 
puter application program into a data set suitable for 
streamed delivery across a network from a server and 

comprising the steps of 

providing installation monitoring means for monitoring 
the installation process of said conventionally coded 
application program on a local computer system; 

wherein said installation monitoring means monitors the 
modifications that said installation process makes to the 
system registry of said local computer system and 
records the system modification data; 

wherein said installation monitoring means monitors and 
records any file modifications made by said mstallation 
process; 

sorting said system modification data and said file modi- 
fication data and removing duplicate entries; 

parameterizing all of said local computer system's spe- 
cific registry keys, value names, and values in said 
system modification data and said file modification 
data; and 

providing data set creation means for processing said 
parameterized system modification data and said 
parameterized file modification data to create a data set 
suitable tor streaming over said network. 

2. The process of claim f , wherein said data set creation 
means creates a runtime data set, said mntime data set 
consists of all regular application files and directories con- 
taining information about said regular application files. 

3. The process of claim 2, wherein said data set creation 
means creates an initialization data set that is the first set of 
data streamed from said server to said client, said initializa- 
tion data set prepares said client for streaming of said 

4. The process of claim 2, wherein said directories contain 
lists of file names, file numbers, and the metadata associated 
with the files in a particular directory. 

5. The process of claim f , wherein said data set creation 
means creates a versioning table that contains a list of root 
file numbers and version numbers for tracking apphcation 
patches and upgrades, and wherein each entry in said 
versioning table corresponds to one patch level of an apph- 
cation with a corresponding new root directory. 

6. The process of claim 5, wherein said versioning table 
is sent to said client by said server, said client compares said 
versioning table with said client's root file number for the 
particular application program to find the necessary files 
required for a software upgrade or patch. 
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7. The process of claim 1, further comprising the step of: 

provrding a user interface that allows an operator to 
examine all changes made to said local computer 
system during said installation process and to edit said 
system modification data and said file modification 

8. The process of claim 1, wherein said installation 
monitoring means monitors said application program as it 
runs and is being configured for a particular working envi- 
ronment on said local computer system and records common 
configurations of said apphcation program thereby aUowing 
said common configurations to be automatically duplicated 
on other client machines. 

9. The process of claim 1, further comprising the step of: 

program profiling means for capturing the sequence of file 
blocks being accessed during normal execution of said 
appKcation program. 

10. The process of claim 9, wherein said sequence of file 
blocks is used to pre-cache frequently used blocks on said 
client before said application program is first used by a user. 

11. The process of claim 9, wherein said sequence of file 
blocks is used to optimize large directories of files on said 
client for faster file accesses. 

12. The process of claim 9, wherein said sequence of file 
blocks is tied to specific user input and wherein said client 
pre-fetches file blocks based on user input to said application 
program. 

13. The process of claim 1, wherein said installation 
monitoring means records the state of said local computer 
system before said instaUation process begins to give a more 
accurate picture of any modifications that are observed by 
said installation monitoring means. 

14. An apparatus for converting a conventionally coded 
computer application program into a data set suitable for 
streamed delivery across a network from a server and 
concurrent execution on a client in a computer environment, 
comprising: 

installation monitoring means for monitoring the instal- 
lation process of said conventionally coded apphcation 
program on a local computer system; 

wherein said installation monitoring means monitors the 
modifications that said installation process makes to the 
system registry of said local computer system and 
records the system modification data; 

wherein said instaUafion monitoring means monitors and 
records any file modifications made by said installation 

a module for sorting said system modification data and 
said file modification data and removing duplicate 



a module for parameterizing all of said local computer 
system's specific registry keys, value names, and val- 
ues in said system modification data and said file 
modification data; and 

data set creation means for processing said parameterized 
system modification data and said parameterized file 
modification data to create a data set suitable for 
streaming over said network. 



15. The apparatus of claim 14, wherein said data set 
creation means creates a runtime data set, said runtime data 
set consists of aU regular application files and directories 
containing information about said regular application files. 

16. The apparatus of claim 15, wherein said data set 
creation means creates an initialization data set that is the 
first set of data streamed from said server to said client, said 
initiahzation data set prepares said client for streaming of 
said runtime data set. 

17. The apparatus of claim 15, wherein said directories 
contain fists of file names, file numbers, and the metadata 
associated with the files in a particular directory. 

18. The apparatus of claim 14, wherein said data set 
creation means creates a versioning table that contains a list 
of root file numbers and version numbers for tracking 
application patches and upgrades, and wherein each entry in 
said versioning table corresponds to one patch level of an 
application with a corresponding new root directory. 

19. The apparatus of claim 18, wherein said versioning 
table is sent to said client by said server, said client compares 
said versioning table with said client's root file number for 
the particular appKcation program to find the necessary files 
required for a software upgrade or patch. 

20. The apparatus of claim 14, further comprising: 

a user interface that aUows an operator to examine all 
changes made to said local computer system during 
said installation process and to edit said system modi- 
fication data and said file modification data. 

21. The apparatus of claim 14, wherein said mstallation 
monitoring means monitors said application program as it 
runs and is being configured for a particular working envi- 
ronment on said local computer system and records common 
configurations of said appKcation program thereby allowing 
said common configurations to be automatically duplicated 
on other client machines. 

22. The apparatus of claim 14, further comprising: 

program profiling means for capturing the sequence of file 
blocks being accessed during normal execution of said 
application program. 

23. The apparatus of claim 22, wherein said sequence of 
file blocks is used to pre-cache frequently used blocks on 
said client before said application program is first used by a 

24. The apparatus of claim 22, wherein said sequence of 
file blocks is used to optimize large directories of files on 
said client for faster file accesses. 

25. The apparatus of claim 22, wherein said sequence of 
file blocks is tied to specific user input and wherein said 
client pre-fetches file blocks based on user input to said 
application program. 

26. The apparatus of claim 14, wherein said installation 
monitoring means records the state of said local computer 
system before said installation process begins to give a more 
accurate picture of any modifications that are observed by 
said installation monitoring means. 

27. A program storage medium readable by a computer, 
tangibly embodying a program of instructions executable by 
the computer to perform method steps for converting a 
conventionally coded computer application program into a 
data set suitable for streamed delivery across a network from 
a server and concurrent execution on a client in a computer 
environment, comprising the steps of: 
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providing installation monitoring means for monitoring 
the installation process of said conventionally coded 
application program on a local computer system; 

wherein said installation monitoring means monitors the 
modifications that said installation process makes to the 
system registry of said local computer system and 
records the system modification data; 

wherein said instaUafion monitoring means monitors and 
records any file modifications made by said installation 
process; 

sorting said system modification data and said file modi- 
fication data and removing duplicate entries; 

parameterizing aU of said local computer system's spe- 
cific registry keys, value names, and values in said 
system modification data and said file modification 
data; and 

providing data set creation means for processing said 
parameterized system modification data and said 
parameterized file modification data to create a data set 
suitable for streaming over said network. 

28. The method of claim 27, wherein said data set creation 
means creates a runtime data set, said runtime data set 
consists of all regular application files and directories con- 
taining information about said regular application files. 

29. The method of claim 28, wherein said data set creation 
means creates an initialization data set that is the first set of 
data streamed from said server to said client, said initializa- 
tion data set prepares said client for streaming of said 

30. The method of claim 28, wherein said directories 
contain Ksts of file names, file numbers, and the metadata 
associated with the files in a particular directory. 

31. The method of claim 27, wherein said data set creation 
means creates a versioning table that contains a list of root 
file numbers and version numbers for tracking apphcation 
patches and upgrades, and wherein each entry in said 
versioning tabic corresponds to one patch level of an appli- 
cation with a corresponding new root directory. 



32. The method of claim 31, wherein said versioning table 
is sent to said client by said server, said client compares said 
versioning table with said client's root file number for the 
particular application program to find the necessary files 
required for a software upgrade or patch. 

33. The method of claim 27, further comprising the step 
of: 

providing a user interface that allows an operator to 
examine all changes made to said local computer 
system during said instafiation process and to edit said 
system modification data and said file modification 

34. The method of claim 27, wherein said instafiation 
monitoring means monitors said application program as it 
runs and is being configured for a particular working envi- 
ronment on said local computer system and records common 
configurations of said appKcation program thereby allowing 
said common configurations to be automatically duplicated 
on other client machines. 

35. The method of claim 27, further comprising the step 
of: 

program profiling means for capturing the sequence of file 
blocks being accessed during normal execution of said 
application program. 

36. The method of claim 35, wherein said sequence of file 
blocks is used to pre-cache frequently used blocks on said 
client before said application program is first used by a user. 

37. The method of claim 35, wherein said sequence of file 
blocks is used to optimize large directories of files on said 
client for faster file accesses. 

38. The method of claim 35, wherein said sequence of file 
blocks is tied to specific user input and wherein said client 
pre-fetches file blocks based on user input to said apphcation 
program. 

39. The method of claim 27, wherein said mstaUation 
monitoring means records the state of said local computer 
system before said installation process begins to give a more 
accurate picture of any modifications that are observed by 
said installation monitoring means. 
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